ESP-basierte projekte und Sicherheit

Begonnen von Horti, 21 Oktober 2019, 07:30:08

Vorheriges Thema - Nächstes Thema

Horti

Guten Morgen,

folgendes Thema liegt mir schon lange am Herzen und ich wundere mich, dass sich noch niemand damit auseinander gesetzt hat (oder ich war nicht in der Lage es zu finden):

Es gibt eine Menge Software- und Hardware-Projekte, die ESP(8266|32) als Basis haben. Die Einrichtung der Software/Geräte läuft dabei meistens nach dem folgenden Muster ab: es wird ein eigenes WLAN mit eigenem AP aufgespannt, man meldet sich daran an, wählt sein Heim-WLAN aus der Liste aus, gibt sein WLAN-Passwort ein und fortan kann sich das Gerät im heimischen WLAN anmelden. Womit ich aber gedanklich ein Problem habe: die WLAN Kommunikation ist ja bei dieser Einrichtung völlig ungeschützt, denn weder WLAN an sich ist verschlüsselt, noch wird https benutzt.

Damit kann doch das WLAN-Passwort des heimischen WLANs einfach mitgeschitten werden? Es mag Projekte geben, die https nutzen, aber mein Eindruck ist, dass die breite Masse es nicht tut. Bei vielen Projekten muss man man schon das WLAN-Passwort im Quellcode eingeben, selber kompilieren und flashen, wenn man das WLAN-Passwort nicht unsicher durch die Gegend funken will.

Übersehe ich irgendwas, ist alles "halb so wild"?

Wenn ich mit meinen Bedenken Recht habe, wie geht man dann damit um, außer Software selbst kompilieren/flashen oder gar nicht nutzen?

Ist WPS eine sichere/sinvolle Alternative?

KölnSolar

Diskutiert wurde das schon öfter.

Ich bin prinzipiell kein Freund von WLAN-Aktoren/-Sensoren. Für mich gehört Smart-Home getrennt vom Internet, was sich leider nicht immer realisieren lässt.

Wenn es denn WLAN sein muss, dann wenigstens in ein 2. Netz, welches möglichst gar keinen Zugang zum Internet hat.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

MadMax-FHEM

Sehe ich ähnlich...

Und wenn ich ESP nutze (mache ich weniger als ich zunächst mal dachte aber eigentl. nicht wegen Sicherheit ;)  ) dann compiliere ich selbst, WLAN Schlüssel dann direkt dort rein und Internetzugang gesperrt...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Horti

Also ist es schon grundsätzlich ein Problem, von der persönlichen Abneigung gegen WLAN in Sachen Smart Home abgesehen (die ich im Übrigen auch teile :) )?

Dann wundert es mich, dass es so wenig getan wird, um das Problem zu lösen/abzuschwächen. Man könnte ja https nutzen, produkt-/versions-/HW-spezifische Initial-WLAN-Passworter nutzen, Möglichkeit zum Vorkonfektionieren der Images mit eigenem WLAN-Passwort vorsehen etc pp.

Wernieman

Bitte beachte die Verhältnisse:

WLAN mit WAP2 (und das macht der esp) ist nun auch nicht gaaaans unsicher. Das Passwort fürs neue WLAN wir normalerweise einmalig eingegeben werden. Ein Angreifer muß also genau zu der Zeit mit lauschen, bzw. vorher wissen, das es interessant wird.

Da sehe ich die ganzen anderen "WLAN-Dinger" viel problematischer: WLAN-Kameras, Roboterstaubsauger ... wie häufig haben Hacker gezeigt, wie einfaxch man dort an die Passwörter kommen kann
... und das vorallem im laufenden Betrieb aus der Ferne. geschweige denn die diversen APS (und Handys), welche solche Infos in die Cloud Pusten.

Allerdings sehe ich den Vorteil eines 2. WLAN auch und habe es deshalb genau so bei mir umgesetzt.

Problematisch sehe ich eher Sicherheitsfunktionen (wie für eine Alarmanlage) und Funk. Dazu ist mir Funk an sich (also nicht nur WLAN) einfach zu unsicher und einfach zu stöhren ... für so etwas gehört Kabel ....

P.S.
esp und https ist einfach wegen der Leistung der Geräte nicht Möglich ....
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

MadMax-FHEM

Naja, mal die Kirche im Dorf lassen...

Der Angreifer muss ja parat stehen, wenn du einen neuen ESP ins Netz nimmst, dann dabei Mim spielen, WLAN Pw abgreifen usw.

Der Moment sollte ja eher kurz sein...

Danach ist das Ding im WLAN und somit so sicher wie eben dein WLAN, da ist dann http/https egal.
Es muss ja erst mal jemand in dein WLAN...

Und dann gleich oder vorher (wenn MAC bekannt bzw. gibt es oft auch die Einstellung beim Router neue Geräte erst mal zu sperren) den Internetzugang abdrehen...

EDIT: zu lahm getippt... ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Horti

Zitat von: Wernieman am 21 Oktober 2019, 08:15:30
Bitte beachte die Verhältnisse:

WLAN mit WAP2 (und das macht der esp) ist nun auch nicht gaaaans unsicher. Das Passwort fürs neue WLAN wir normalerweise einmalig eingegeben werden. Ein Angreifer muß also genau zu der Zeit mit lauschen, bzw. vorher wissen, das es interessant wird.

Das ist zwar tröstlich, wenn der Angreifer immer mitlauscht und nur bei diesem Muster aktiv wird/mitschneidet, dann hat er ein leichtes Spiel. Und ja, ich weiß, wer in mein Netzwerk will, der kommt, entsprechende Ressourcen vorausgesetzt, immer rein. Aber dass hier so eine Tür bewusst offen gelassen wird? Vielleicht bin ich auch nur zu paranoid  ;)


Zitat von: Wernieman am 21 Oktober 2019, 08:15:30
esp und https ist einfach wegen der Leistung der Geräte nicht Möglich ....

OK, dass ist natürlich eine handfeste Begründung, das war mir nicht klar

Zitat von: MadMax-FHEM am 21 Oktober 2019, 08:15:33
Der Angreifer muss ja parat stehen, wenn du einen neuen ESP ins Netz nimmst, dann dabei Mim spielen, WLAN Pw abgreifen usw.

"Mim" muss man doch dabei nicht spielen, man braucht nur fleißig mitzuschneiden und dann in Ruhe auswerten, oder?

Wie auch immer, danke für Eure Antworten, ich weiß nun, dass meine Bedenken nicht unbegründet waren und werde mir überlegen, wie ich mit diesem Thema umgehe!

MadMax-FHEM

Zum Mitschneiden musst du ja irgendwie dazwischen und Pakete mitlauschen...

Lauschen auf der Luft geht nat. ist aber halt auch aufwändiger...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Wernieman

24x7 lauschen um genau den Moment der Eingabe zu Wissen? Sorry aber da gibt es einfachere Möglichkeiten.

Grundsätzlich verstehe ich Deine bedenken und ich habe sie auch, aber nicht gerade in dem Bereich.

Mir sind ESP mit "bekannter" Software lieber, als irgendwelches Gedöns von irgendwelchen Firmen, wo man nicht weiß, was man sich "in die Bude" holt. Und da spreche ich nicht von "China-Kram", sondern auch Sprachsteuerungen 8Auch wenn sie im Endeffekt aus China kommt) ....

- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

pcbastler

Ich hab mich bewusst für ein paar Tasmota-Geräte entschieden, aber:
- Mein WLAN hat einen MAC-Filter (openWRT auf TPLink)
- Das Konfig-WLAN des Tasmota-Geräts ist max. 5 min vorhanden

Der Preisvorteil (4x Teckin SP21 für 34€ gegen 1x Homematic) war einfach unschlagbar. Glücklicherweise reicht das heimische Class-C-Netz (192.168.x.y) für den Eigenbedarf noch aus. Ansonsten kommt ein neuer OpenWRT-tauglicher Router für das IOT-WLAN ins Haus ;)

Wernieman

ZitatMein WLAN hat einen MAC-Filter (openWRT auf TPLink)

Wobei Du damit nur die Script-Kiddies ärgerst .... MAC-Clonen ist "bei den bösen" heute Standard und deshalb wird im Firmenumfeld MAC-Filter nicht mehr als Sicherheitslösung anerkannt ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

rob

Das IoT ins eigene Netz zu sperren klingt vernünftig. Unterm Strich ist es Sicherheit vs. Benutzbarkeit. In der c't hatte ich einst vom Cisco Zone Concept gelesen, welches mit kaskadierten Fritzboxen beispielhaft realisiert wurde - interessant, aber für mich overkill (ich häts gerne am Beispiel OpenWRT mit einem Router gesehen :().

Zitat von: Wernieman am 21 Oktober 2019, 08:15:30
Funk an sich (also nicht nur WLAN) einfach zu unsicher und einfach zu stöhren ... für so etwas gehört Kabel ....
Wenn man es sehr ernst meint mit Alarm u. Co. wird m.E. ein eigener Stromkreis nebst eigenem FI Pflicht ohne Leitung nach außerhalb d. vier Wände. Sonst muss einer nur zur Steckdose auf der Terrasse gehen und mal kurz PE mit L verbinden - voila alles tot, weil viele Häuser nur einen FI haben (in Wohnhäusern ist der Raum mit den Verteilern oft nichtmal abgeschlossen ...).
Ferner wäre dieser Stromkreis via USV zu stützen usw. usw.
Man kann Sicherheit bis zum Exzess betreiben. Der nötige Kompromiss ist dann meist recht individuell, weil jeder andere Schwerpunkte setzt/setzen muss.

Die Esp's finde ich mit Firmata oder EspEasy recht sicher. Mehr Kopfschmerzen würden mir da Datenparasiten á la Alexa und GoogleSonstwas machen. Fhem=cloudfree und dann kommt da auch kein Datenkrake drangeklebt  ;D

Viele Grüße
rob

Wernieman

Also eigenen Stromkreis wäre wirklich oversized. Aber für Alarmanlage (und nur darüber sprach ich) sollte USV (o.Ä.) immer Standard sein.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

rob

@Wernieman
Bitte nicht missverstehen, ich würde auch Kabellösungen vorziehen, wo immer möglich. Ich wollte nur darstellen, dass es Situationen geben kann, wo das allein noch nicht reichen mag.
z.B. Fhem als "Alarmanlage", wo der Alarm über Telegram/Mail rausgeht. Da gibt es schnell recht viel zu puffern.

Tatsächlich habe ich den ganzen Fhem-Zoo im Kasten am eigenen Stromkreis/FI. Dazu gehört dann alles was mir Alarm-relevant vorkommt  ;D
Absolute Sicherheit erreiche ich damit freilich nicht. Blitze oder Stromausfälle >1/2h usw. legen mir auch alles schachmatt  :o

Viele Grüße
rob



Wernieman

Also Prinzipiell würde ich FHEM auch nciht als Alarmanlage sehen, da gehört etwas mehr dazu ... Alarmsignalisierung ist dagegen etwas anderes ;o)
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

dtavb

#15
Schätze, das Thema kann auf so viele Weisen betrachtet werden. Denke die meisten betrachten das Thema mit den ESPs & HTTP (noch) nicht als relevant an.

An meinem Beispiel: mich interessiert es nur sekundär ob HTTPs bei ESPs genutzt wird, denn ich baue viel Sicherheit darum - da ist es vermutlich egal. Sicherer geht immer, das sehe ich allerdings auch so!
Ich überlege auch immer wieder wie und was ich tun kann um meine Umgebung abzusichern - im Kontext von Eindringlingen via Internet oder ein böser Hacker vor Ort. Das ganze ist allerdings unter so vielen Gesichtspunkten zu betrachten, dass es für den Heimgebrauch schlicht oversized ist oder bei dem einen oder anderen aufgrund des Jobs effizienter erledigt werden kann. Wenn ein Hacker in ein WiFi rein will, dann schafft er das bei wohl vielen Heim-WiFi Betreibern. Es gibt vermutlich nur sehr wenig Heim-Installationen die einem Roque-AP standhalten...gut gesicherte WiFi haben beispielsweise APs installiert, die fremde APs blockieren, bzw. fremden Clients sofort Disconnects senden und zusätzlich noch mit Zertifikaten arbeiten.

Wer mit IoT beginnt, sollte meiner Meinung nach zu aller erst eine Firewall (pfsense, opnsense, openwrt etc.) haben, also die reine Netzsicht wer was darf. Zusätzlich sollte überall wo Applikationen betrieben werden mit einem OS-Monitoring überwacht werden (Antivirus, Server/Client-Firwall) oder beispielsweise OSSEC. Dann können einem irgendwelche China-Geräte schon nicht mehr so gefährlich werden oder nach Hause funken. Kein Gerät darf ohne Genehmigung ins Internet oder auf einem "wichtigen" Steuerungssysteme zugreifen. Andere Netze, getrennt durch eine Firewall für IoT halte ich schon wieder für oversized oder bei manchen Dingen wie Alexa aufgrund von Multicast etc. für so aufwendig zu konfigurieren, dass es keinen Spass mehr macht. Habe es versucht und bin kläglich (an meinem Unvermögen) gescheitert Multicast-Domänen über verschiedene Netze einzurichten, damit Alexa und Sonos, samt habridge irgendwie mit FHEM zusammen arbeiten. Nach einem Gespräch mit meinem Firewall/Security Spezi des Vertrauen: "lass die Finger davon"..."Ist nicht für so ein Umfeld gedacht [bla bla bla]". Ursprünglich wollte ich 3 DMZs erstellen: Client, Server, IoT. Dabei aber schon gemerkt, dass eigentlich simple Dinge plötzlich ausführlich bedacht werden müssen: brauchen manche Server 2 Netzwerk-Interfaces, mag ich ganz allgemein VLANs einführen, muss ich beim Routing etwas beachten, wie schaut es mit Broadcast/Multicasts aus etc.

Auch das gehört zur Absicherung dazu: Backups, ohne gescheite Backups und Redundanzen wird es äusserst frustrierend mit Ausfällen, Datenverluste etc. oder auch einfach menschliche Fehler beim Basteln/Konfigurieren.

Desweiteren nutzt es nichts FHEM nur auf Applikationsebene abzusichern, wenn der Server (egal ob VM oder Pi etc.) offen wie ein Scheunentor ist und jede Daemon/Dienst auf allen Interfaces läuft. Aus diesem Grund habe ich recht viel reglementiert und daher auch auf den CRSF-Token verzichtet (bitte nicht hauen). Vor FHEM ist bei mir ein haproxy und ich schaue ich immer mal wieder im Netz nach best-practises wie man einen dahinter sitzenden Server schützt. Da kann ich auf den Token verzichten. Ehrlich gesagt weiss ich gar nicht mehr warum ich den nicht aktiviert habe, glaube es war habridge...
Auch hier wieder: wie weit möchte man es treiben und letztendlich der wichtigste Punkt: wie viel Zeit hat man dazu? Ich versuche grundsätzlich den Zugriff auf den Server zu regelmentieren: ssh-key etc. Dann kann irgendein Gerät machen was es will, es kommt nicht an den FHEM-Server ran. Alternativ auch sehr strenge Firewall-Regeln auf dem FHEM-Server selbst (iptables, nftables, ufw etc), oder gar: Jump-Host. Auf wichtige Strukturen darf man nur von einem Server/System aus zugreifen (zB Apache Guacamole).

Und ganz spannend wird es dann mit VPNs oder geofency-Zeugs: dann müssen Portweiterleitungen, natting etc. konfiguriert werden. Das muss ausgiebig gesichert werden.
Welche Ports benutze ich im Netzwerk für meine Dienste: nutze ich die Standard-Ports für meine Applikationen und kann man die auch getrost ändern. Geht ja auch nicht immer, Beispiel Alexa oder Google smartHome Geschichten oder auch Lets encrypt möchte unbedingt auf Port 80 verbinden.

Danach kommt man meist zu dem Punkt: ok, "alles" gesichert und wie kann ich jetzt überwachen, was so geschieht? Schon beschäftigt man sich mit Monitoring (Nagios,Icinga) oder Grafana, Kibana etc. damit man hübsche Ansichten erhält... auch wieder ein Fass ohne Boden. Messaging erwähne ich jetzt nur, benötigt man ja auch irgendwie wenn man schon so tief im Sumpf ist :)

Mit WiFi/Netzwerk kenne ich mich persönlich besser aus wie mit Z-Wave/Zig-Bee etc. Daher fällt es mir leichter dies abzusichern als andere Medien. Im Grunde gehe ich davon aus, dass ein Eindringling ruhig mein Z-Wave Tür-Sensor kapern kann. Ob ein Bösewicht darauf etwas installieren kann, um mir gefährlich zu werden, wage ich zu bezweifeln und ins WiFi kommt er dann immer noch nicht. Naja, auch das stimmt nicht unter allen Umständen: Stichwort Alarmanlage und Einbruch...da interessiert es schon mehr, ob man Sensoren überlisten oder übernehmen kann. Ich betreibe FHEM allerdings nicht als Alarmanlage. Ich habe solche Sensoren nur installiert, damit ich beim Verlassen des Hauses weiss ob alles so ist wie es sein soll, Stichwort Tiere.

Was ich damit sagen will: es gibt so viel zu sichern, da ist ein IoT ESP mit HTTP das geringste aller Probleme...eine Alu-Haube drüber und schon hat der Angreifer an der Tür keine Chance mehr (Spass). Trotzdem gebe ich Dir recht, bei all diesen IoT Zeug: da muss Sicherheit ebenso berücksichtigt werden wie bei allen anderen auch.

fhem:pi3&kvm, z-wave, it-funk, milight, zigbee, wifi, bt & presence, geo-tracking, alexa, esp.
Monitoring: ELK(syslog), grafana (grafik), netdata (ermittlung)
Security: haproxy (access), ossec (überall), snort (access), opnsense (fw)
Geplant: KVM-Cluster