ESP-basierte projekte und Sicherheit

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

Vorheriges Thema - Nächstes Thema

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