HINWEIS: Alle Angaben beziehen sich auf die CCU2 (und nach derzeit verfügbaren Infos auch für die CCU3) , entsprechen meinem derzeitigen Wissenstand und können daher auch unvollständig oder falsch sein. Bei PC-Werkzeugen beziehe ich mich auf Windows. Linux-Workstation-Benutzer werden die Linux-Pendants dazu wahrscheinlich ohnehin kennen.
Versionierung
16.11. Input von user DrTob und Xel66 zu 1.3 übernommen
17.11. Link-Hinweis von user dtp zu 1.3 und
Hinweis auf VPN von user Sammy in 7.3 übernommen
Abschnitt über VLAN nach 2.3 verschoben
21.11. Abschnitt über UPnP in 7.2 und 7.3 hinzugefügt.
22.11. Im Abschnitt 7.2 und 7.3 Internet Zugang via Teamviewer hinzugefügt.
31.12. Im Abschnitt 7.3 die Aktivierung des HTTPS Zugriff zur CCU beschrieben
6.2.17 Im Abschnitt 7.3 Hinweis auf eine Security Server Lösung eingefügt.
22.2.17 Im Abschnitt 7.3 Hinweis von user iRudi auf VPN split tunneling eingeführt
21.10.17 Im Abschnitt 2.2 und 2.3 Hinweis auf Sicherheitslücke KRACK im WLAN WPA/PSK/TKIP
11.7.18 Hinweise auf CCU3 und Bausatz "Charly"
16.3.19 Kapitel 8, Externe Services hinzugefügt
14.2.20 Port 48181 (ab FW 2.51.6), SSL Unterstützung für „Remote Homematic-Script API“ eingefügt. Neuer Name für Meinhe HomeMatic.de ist nun CloudMatic.
Allgemeines
Die HM CCU ist als sehr offenes System konzipiert. Das hat den unschätzbaren Vorteil, dass man praktisch für alle auftauchende Aufgaben und Probleme eine Lösung findet. Die vielen Projekte und Tipps hier im Forum sind der beste Beweis dafür.
Andererseits kann Offenheit aber auch ein Problem werden, wenn Unbefugte am Werk sind und Böses wollen. Daher muss jeder Betreiber eines HM Systems meiner Ansicht nach wissen, auf was er sich einlässt. Im Bereich Security ist Wissen und Informationsvorsprung letztendlich die einzige wirksame Waffe gegen Angreifer.
Schnittstellen und Schutzmaßnahmen
Jede Schnittstelle eines Systems nach außen ist potenziell ein Sicherheitsrisiko. Andererseits wäre ein System ohne Schnittstellen völlig nutzlos. Schnittstellen sind also gut und sinnvoll, müssen aber gegen Mißbrauch geschützt werden.
Die CCU2 verfügt über folgende Schnittstellen:
- 1. BidCoS
- 2. LAN
- 3. USB Client
- 4. USB Host
- 5. Micro SD
- 6. Sonstige
- 7. Internet (Router)
- 8. Externe Services (CloudMatic, Alexa und Co.)
Anders beim ebenfalls angekündigten CCU Bausatz "Charly". Dieser basiert auf einem "echten" Raspberry Pi Modell 3B und einem Funkmodul für das BidCoS Protokoll, verfügt daher über alle Raspi Schnittstellen und 4 USB Anschlüsse.
- 8. GPIO Pins
- 9. MIPI CSI camera port
- 10. Bluetooth
- 11. WLAN
- 12. HDMI
Die Software (WebUI, Rega, XML Api etc.) ist bei CCU3 und Charly im Wesentlichen gleich wie bei der CCU2. Allerdings sollen nun Direktverknüpfungen zwischen HomeMatic und Homematic IP Geräten (angeschlossen über ein Gateway) möglich sein. Auf der CCU3 wird zusätzlich ein Homematic Plug-in für AIO Creator Neo und ein Mediola Neo-Server installiert sein.
Damit gelten - soweit mir bisher bekannt ist - bis auf Abschnitt 5 alle u.a. Überlegungen auch für CCU3 und Charly.
1. BidCoS – Funkschnittstelle
1.1 Aufgabe
Kommunikation mit batterie- oder netzbetriebenen Sensoren (z.B. Wassermelder oder 6-fach Wandttaster) und Aktoren (z.B. Funksteckdose oder Funk-Gong) des HM Systems im 868 MHz Band.
1.2 Standard-Einstellung
Die CCU kommuniziert mit angelernten Geräten unverschlüsselt. Daher kann mit entsprechenden Funkempfängern der Datenstrom mitgelesen werden. Angreifer können damit z.B. Hinweise auf Lebensgewohnheiten der Hausbewohner auskundschaften, wenn sie sich im Umkreis der Funkreichweite der CCU (200m) befinden.
Es gibt zwar einen Standard-Sicherheitsschlüssel, der zur Authentifizierung der Kommunikationspartner (angelernte Geräte) verwendet wird. Der Standard-Sicherheitsschlüssel ist aber offenbar geknackt. Mit entsprechendem Aufwand können Angreifer also Nachrichten von Sensoren fälschen bzw. Aktoren unbefugt schalten.
Das BidCoS Protokoll arbeitet bidirektional. Daher besteht ein gewisser Schutz gegen Übertragungsfehler. So kann ein Sender feststellen, ob der Empfänger eine empfangene Nachricht bestätigt hat (Er kann nicht feststellen, ob der Empfänger die Nachricht erhalten hat). Wenn keine Bestätigung vorliegt, wiederholt der Sender die Nachricht. Bei einigen Geräten kann die maximale Zahl der Wiederholungen eingestellt werden.
Es ist eine (gesetzlich vorgeschriebene) Schranke eingebaut, die dafür sorgt, dass keine einzelne CCU den Funkkanal ständig belegen kann (duty cycle limit). Ist dieses Limit überschritten, so stellt die CCU den Funkverkehr ein.
1.3 Schutzmaßnahmen
Die Nachrichten an sicherheits-relevante Aktoren/Sensoren werden sicher authentifiziert, wenn in der CCU ein eigener Sicherheitsschlüssel vergeben wird, also nicht der Standard-Sicherheitsschlüssel verwendet wird. Das Senden gefälschter Sensordaten bzw. das unbefugte Schalten von Aktoren ist damit nicht mehr möglich. Das gilt aber nur für jene Komponenten die die Verschlüsselung auch beherrschen. Mit einem Störsender ist eine Blockierung des Funkverkehrs bzw. eine erhebliche Verzögerung der Übertragung denkbar.
Die Kommunikation über BidCoS erfolgt also nicht verschlüsselt. Mithören können Angreifer im Funkbereich der CCU immer wenn sie aktiv ist (egal ob der Schlüssel geändert wurde oder nicht). Aber die Gegenstelle wird sicher authentifiziert, wenn der Systemschlüssel geändert worden ist. Gefälschte/nicht angelernte Absender werden also ignoriert.
Das ist anders als im WLAN. Dort wird der Datenstrom (bei aktiviertem WAP) verschlüsselt aber ausser bei HTTPS-Verbindungen wird die Gegenstelle nicht sicher authentifiziert. Im WLAN kann sich also U als X ausgeben, wenn er das WLAN Passwort kennt und der Server eine HTTP (ohne S) Verbindung akzeptiert.
HINWEIS: Wenn man in der CCU einen eigenen Sicherheitsschlüssel vergibt, ist es notwendig sich beim Entfernen von Komponenten aus dem System oder bei einer Neuinstallation an die im WebUI Handbuch angeführten Regeln zu halten (siehe auch http://homematic-forum.de/forum/viewtop ... l+vergeben). Ansonsten können Komponenten nicht wieder angelernt werden (unter https://files.elv.com/downloads/forum/s ... 0_2012.pdf gibts weitere interessante Infos. Die dortige Empfehlung, für private HM Netze keinen eigenen Sicherheitsschlüssel zu setzen, halte ich aber für veraltet, weil eben der Standardschlüssel geknackt wurde und daher sicherheitstechnisch bedenklich .)
Ein vergessener Schlüssel beeinträchtigt die Funktion des Systems nicht, da der Sicherheitsschlüssel beim Anlernen neuer Komponenten auf diese übertragen wird. Allerdings wird der Sicherheitsschlüssel beim Einspielen/Restore von Backups benötigt. Daher ist es notwendig sich zu jedem Backup aufzuzeichnen, welcher Sicherheitsschlüssel gültig war, als das Backup angelegt wurde.
HM Systeme müssen in jedem Fall so geplant werden, dass ein Ausfall oder Verzögerung eines Schaltbefehls keine Risiken wesentlich erhöhen oder verursachen kann. Deswegen darf man eine konventionelle Bahnschranken-Steuerung nicht durch eine CCU2 ersetzen
. Aber es hat Sinn eine neue Alarmanlage mit der CCU2 aufzubauen, denn das erhöht das Einruchs-Risiko nicht, sondern belässt es im schlechtesten Fall gleich.2. LAN Schnittstelle (TCP/IP via Ethernet)
2.1 Aufgabe
Über LAN Kabel wird die TCP/IP Schnittstelle der CCU im LAN bereitgestellt. Über Die IP-Adresse der CCU können andere Geräte (PC’s, Tablets, Smartphones, aber auch andere Server wie ein NAS, Raspberry Pi etc.) über diese Schnittstelle mit der CCU kommunizieren. Auf der CCU laufen verschiedene Server-Dienste, die Anfragen über unterschiedliche TCP/IP Ports entgegennehmen und beantworten. Die Schnittstelle erlaubt es nicht nur Daten abzufragen, sondern auch Aktoren über BidCoS zu schalten, die Konfiguration zu verändern, Programme und Scripte zu installieren und die Software der CCU zu verändern und zu sichern.
2.2 Standard-Einstellung
Wenn es im LAN einen WLAN-Router gibt (wie wohl in den allermeisten Häusern) kann auf diese Schnittstelle auch aus dem WLAN oder – entsprechende Einstellungen vorausgesetzt – aus dem Internet zugegriffen werden.
Die Standard-Einstellung der meisten Router ist, dass auf die LAN-Schnittstelle der CCU zwar aus dem lokalen LAN und WLAN zugegriffen werden kann, nicht aber aus dem Internet. (Programme auf der CCU können aber von sich aus ins Internet kommunizieren. Daher ist die CCU etwa in der Lage ohne Änderung der Router Konfiguration E-Mails an einen E-Mail Server zu versenden, wenn das E-Mail Addon installiert ist (oder Verbindung mit dem „meine Homematic“/CloudMatic-Server aufzunehmen).
Im Oktober 2017 ist die KRACK Sicherheitslücke im WLAN WPA Protokoll bekannt geworden. Siehe dazu auch diesen Thread im Forum. Es sei zwar nicht möglich das WPA Passwort zu ermitteln und sich so mit dem WLAN zu verbinden, aber es ist offenbar möglich übertragene Daten zu verändern. Damit sind viele weitere darauf aufbauende Angriffsvektoren denkbar. Ein Angreifer könnte so darauf warten bis irgendein angemeldeter Client irgendeinen Request an die CCU sendet und unerwünschte Schaltvorgänge - etwa über das XML/API (s.u.) - auslösen oder solche verhindern.
Folgende Dienste bietet die CCU für den Zugriff von außen an:
Port 80: WebUI
Wenn man von einem Browser im LAN/WLAN [url]http://<ip-adresse-der-ccu>[/url] oder [url]http://<ip-adresse-der-ccu>:80[/url] aufruft, antwortet das WebUI, die Standard-Benutzeroberfläche der CCU bzw. der Lighttpd Webserver auf der CCU. Das Interface ist Passwort-geschützt. Die Übertragung der Daten erfolgt standardmäßig aber unverschlüsselt und kann daher auf jedem Gerät im LAN/WLAN mitgelesen werden. Das gilt auch für die Passwörter.
Port 90: PHP Addon
Auf CCU2 nicht unterstützt.
Port 22: SSH und SFTP
Diese Schnittstelle erlaubt den Zugriff auf das Dateisystem der CCU mit allen Administrator (root) Rechten. Sie ist standardmäßig ausgeschaltet und kann über das WebUI aktiviert werden. Auch das Passwort wird über das WebUI eingestellt. Wer also mit Admin Rechten das WebUI erreicht, hat grundsätzlich auch Zugriff zum Dateisystem der CCU.
Für den Zugriff vom PC aus benötigt man Werkzeuge wie FileZilla oder WinSCP. Mit beiden kann man Dateien hin- und herkopieren, verändern oder Zugriffsrechte setzen. WinSCP bietet auch ein Kommandozeilen-Fenster mit dem man beliebige Linux-Kommandos aufrufen kann.
Port 2001- 2002: XML-RPC
Siehe http://homematic-forum.de/forum/viewtopic.php?t=4827 und http://www.elv.at/Via-Netzwerk-auf-Home ... tail_30789 . XML-RPC ist auf jeder CCU aktiv und nicht zu verwechseln mit dem Addon XML-API.
Über Port 2000 (drahtgebundene, nur in der CCU1) und Port 2001 (funkgesteuerte, an CCU1 und CCU2) kann man direkt auf Aktoren und Sensoren zugreifen. Genau so wie es die WebUI Programme auch machen. Port 2002 ist für den Zugriff auf CCU interne Geräte. Um ein Gerät zu schalten oder einen Zustand abzufragen, muss man über die Schnittstelle einen XML-String an die CCU senden und bekommt einen XML String zurück. Es ist auch möglich etwa einen eigenen PC/Server bei der CCU zu registrieren. Dann sendet die CCU immer, wenn sich etwas ändert, einen XML-String an den PC/Server, der diesen dann auswerten kann (publish-subscribe Muster).
Die Schnittstelle ist weder Passwort-gesichert noch verschlüsselt.
Port 8001-8002: reserviert für die Zukunft
Port 8181: Script Engine / Remote Homematic-Script API
Über diese Schnittstelle kann man Kommandos der CCU Script-Sprache als HTML Parameter absetzen, also zum Beispiel den Status eines Sensors abfragen, einen Aktor schalten oder ein WebUI Programm aufrufen (Beispiel: http://<ccu-ip>:8181/egal.exe?go=dom.GetObject(<pgmid>).ProgramExecute(); ) . Das Ergebnis kommt in einer XML Struktur zurück. (Es können per http-post aber auch ganze Skripte übergeben werden. Siehe z.B. dieses PHP Beispiel)
Die Schnittstelle ist weder Passwort-gesichert noch verschlüsselt.
Port 48181: Script Engine / Remote Homematic-Script API via SSL
Seit Firmware 2.51.6 . Näheres wird noch ergänzt.
Port 8182 und 8183: INFO-LED und Web-Proxy
Ab Firmware 2.29.18: Port 8182 des Web-Proxies nach 8183 geändert.
Port 8182 wird zur Ansteuerung der INFO-LED bei Service-Meldungen benutzt. Näheres wird noch ergänzt.
2.3 Schutzmaßnahmen
Wenn man von der CCU weder nach außen kommuniziert (auch keine E-Mails etc. versenden will) und auch nicht von einem PC aus und auch nicht vom Internet aus auf die CCU zugreifen will, und auch kein HM LAN-Gateway betreibt, kann man das LAN Kabel abstecken. Der Schutz ist damit perfekt, wird aber leider nur selten praktikabel sein.
Braucht man die Verbindung, kann auf der CCU (unter Einstellungen/ Systemsteuerung/ Netzwerkeinstellungen) HTTPS aktiviert werden. Das angebotene SSL Zertifikat ist aber nicht signiert und daher nicht geeignet die CCU im Netz eindeutig zu authentifizieren. Webbrowser stufen die Verbindung zur CCU daher weiterhin als unsicher ein. Es wird dabei auch keine HTTP Benutzer-Authentifizierung aktiviert (also kein Passwortschutz etwa für das XML-API).
Es wird zwar der Traffic zwischen Client und Server verschlüsselt, für eine sichere Freigabe des Zugriffs auf die CCU mittels Portweiterleitung (siehe Abschnitt 7) ist diese Funktion aber nicht ausreichend.
Es ist auch sinnvoll mit dem Skript CCU-Protect (vom user blackhole hier im Forum) den Zugriff auf bestimmte Geräte (eigenen PC, Server) im LAN/WLAN einzuschränken und so Angriffe aus dem eigenen LAN/WLAN zu erschweren. Da dabei nach IP-Adressen oder MAC-Adressen gefiltert wird, beide aber "gefälscht" werden können, ist dieser Schutz nicht hundert-prozentig.
Ein Patch im WLAN-Accesspoint (WLAN-Router) sollte ausreichen um die Sicherheitslücke KRACK im WPA2 Protokoll von WLANs zu schließen. Es empfiehlt sich auf jeden Fall zu prüfen, ob ein solcher Patch für den eigenen Router verfügbar ist. Siehe Hersteller Updates .
Solange es keinen Patch für den Router gibt, hat es Sinn: ggf. das WLAN abzuschalten, die CCU in ein eigenes vom WLAN aus nicht erreichbares Subnetz zu geben, in der CCU HTTPS zu aktivieren (erschwert Angriffe) oder eine Firewall, wie den SCS vorzuschalten. Das ist für alle weiter unten angeführten Punkte relavant, in denen die Sicherheit des Zugangs zur CCU vom WLAN abhängt.
Je nach Port können/müssen unterschiedliche weitere Schutz-Maßnahmen gesetzt werden.
Port 80: WebUI
Es können Benutzer der Berechtigungstufe
• Gast (sieht nur für ihn freigegebene Favoriten-Seiten)
• Benutzer (kann keine Programme ändern oder Geräte anlernen) oder
• Administrator
angelegt werden. Am Wichtigsten ist es ein gutes WLAN Passwort zu vergeben und dieses, wie den Zugriff auf die LAN Verkabelung nur an vertrauenswürdige Personen weiterzugeben. Noch besser, wenn es der Router unterstützt: ein eigenes Gäste-Subnetz mit eigenem Passwort zu definieren, das lediglich einen Zugriff aufs Internet erlaubt, aber nicht auf lokale Ressourcen wie die CCU. Es ist trotzdem sinnvoll insbes. für den Administrator ein sicheres Passwort in WebUI zu vergeben.
Port 80: XML-API
Die XML-API ist ein Addon (nicht zu verwechseln mit XML-RPC), das zum Download angeboten wird und ermöglicht die Kommunikation mit Geräten und Aufruf von Programmen. Die Kommunikation ist weder verschlüsselt noch Passwort geschützt (Aufruf z.B. http://<ip-der-ccu>/config/xmlapi/programlist.cgi und http://<ip-der-ccu>/config/xmlapi/runprogram.cgi?program_id=12345 ) .
Es ist möglich am Lighttpd Server der CCU eine basic authentication einzurichten und somit auch dem XML-API einen Passwortschutz zu geben. Da die Kommunikation aber standardmäßig unverschlüsselt erfolgt, können Mitleser im LAN/WLAN ein solches Passwort einfach auskundschaften. Das kann man mit der oben beschriebene HTTPS Funktion der CCU verbessern aber nicht vollständig lösen(s.o.).
Es ist sinnvoll mit CCU-Protect vom User „blackhole“ hier im Forum den Zugriff auf die CCU nur auf bestimmte Geräte (eigenen PC, Server) im LAN/WLAN einzuschränken. Wie oben erwähnt ist das auch kein 100-prozentiger Schutz.
Sicher wird’s, wenn man das heimische LAN/WLAN physisch in zwei oder mehrere virtuelle LANs, VLANs unterteilt, wie das manche Router und Switches können. Wenn man Security Server und CCU in ein VLAN gibt und die anderen Geräte, also z.B. den eigenen PC, die Smartphones der Kinder und der Gäste in ein anderes VLAN, dann ist die CCU sicher, weil beide VLANs zwar Internet Zugriff anbieten, aber ein Zugriff auf Geräte im jeweils anderen VLAN , etwa via [url]http://<ip-adresse-der-ccu>:80[/url] , nicht möglich ist. Wer aus dem anderen VLAN auf die CCU zugreifen will kann das also nicht via [url]http://<ip-adresse-der-ccu>:80[/url] tun, sondern muss auf die CCU etwa via [url]https://<öffentliche-ip-adresse-des-routers>:801[/url] zugreifen (siehe Abschnitt 7.3 zur Einrichtung einer sicheren Port-Weiterleitung und eines Security Servers für Zugriff auf die CCU) und das ist nur verschlüsselt möglich und nur wenn man das Passwort kennt.
Manche Router, wie etwa der TP-Link Archer MR200 können auch ein eigenes Gäste-Netzwerk definieren. Man kann für das Gäste-Netzwerk den Zugriff auf das Haupt-Netzwerk (wo sich CCU und Security Server befinden) unterbinden. Das bringt den gleichen Sicherheitsgewinn wie ein VLAN.
Port 90: PHP
Darüber liegen mir keine Informationen vor.
Port 22: SSH und SFTP
Es ist sinnvoll ein starkes Passwort zu vergeben und ggf. über das WebUI den SSH Zugang abzuschalten, wenn man ihn nicht benötigt. Hat man vorher ein Backup gemacht, dann kann man dieses (mit aktiviertem SSH Zugang) einspielen, wenn es Probleme geben sollte, die man über WebUI nicht lösen kann.
Port 2001- 2002: XML-RPC
Siehe http://homematic-forum.de/forum/viewtopic.php?t=4827 und http://www.elv.at/Via-Netzwerk-auf-Home ... tail_30789
Über die CCU Firewall in den WebUI Einstellungen sollte man den Zugriff auf bestimmte IP-Adressen (eigener PC, vertrauenswürdiger Server) einschränken oder ganz unterbinden, wenn man ihn nicht benötigt.
Port 8001-8002: reserviert für die Zukunft
Port 8181: Script Engine
Über die CCU Firewall in den WebUI Einstellungen sollte man den Zugriff auf bestimmte IP-Adressen (eigener, Passwort geschützter PC, vertrauenswürdiger Server) einschränken oder ganz unterbinden, können wenn man ihn nicht benötigt.
HINWEIS: Auf meiner CCU funktioniert diese Einschränkung auf bestimmte IP-Adressen allerdings nicht.
3. USB-Client Schnittstelle (zum PC)
3.1 Aufgabe
Über diese Schnittstelle kann man einen PC mit der CCU verbinden. Die CCU kann dann von diesem PC aus ebenso angesprochen werden, wie über die LAN-Schnittstelle.
3.2 Standard-Einstellung
Siehe LAN Schnittstelle.
3.3 Schutzmaßnahmen
USB Kabel abstecken.
4. USB-Host Schnittstelle für USB-Stick
4.1 Aufgabe
Die CCU kann einen USB Speicherstick über die USB Schnittstelle ansprechen. Die USB Schnittstelle kann auch für die Kommunikation mit anderen Funk-Systemen (z.B. FS20, EnOcean…) verwendet werden.
4.2 Standard-Einstellung
Speicher-Sticks werden als Verzeichnis gemountet. Theoretisch können USB Sticks über eine modifizierte Firmware Schadsoftware übertragen. Daten könnten durch Entfernen des Sticks gestohlen werden.
Was andere Sticks betrifft, fehlen mir Erfahrungen.
4.3 Schutzmaßnahmen
Gegen Datendiebstahl hilft Einsperren und Verstecken der CCU. Sonst keine Schutzmaßnahmen bekannt.
5. Schnittstelle zur Micro-SD Karte
Dieser Abschnitt gilt nicht für die CCU3. Die CCU3 hat keine Extra Schnittstelle für eine Micro-SD Karte.
Beim Bausatz Charly gibt es, wie bei allen Raspberry Pi Modellen, einen Slot für eine Micro-SD Karte auf der, anders als bei der CCU2, allerdings nicht nur Daten sondern auch das Betriebssystem gespeichert sind.
5.1 Aufgabe
Erweiterung des nicht-flüchtigen Speichers der CCU.
5.2 Standard-Einstellung
SD Karten werden als Verzeichnis gemountet, ins Dateisystem der CCU eingebunden. Da die CCU nicht von sich aus Programme in diesen Verzeichnissen startet, ist das Schadsoftware Sicherheitsrisiko gering. Daten könnten durch Entfernen der Karte gestohlen werden.
5.3 Schutzmaßnahmen
Gegen Datendiebstahl hilft Einsperren und Verstecken der CCU. Sonst keine Schutzmaßnahmen bekannt.
6. Sonstige Schnittstellen
Wenn man so will, sind die LED’s und die Stromversorgung auch Schnittstellen nach aussen. Aber da sie nur relativ wenige Informationen nach aussen übertragen, wollen wir die LED‘s nicht weiter betrachten.
Die Stromversorgung ist ein anderes Thema. Es empfiehlt sich die CCU an einer USV zu betreiben. Da sie relativ wenig Strom braucht, erzielt man schon mit kleinen, preiswerten Anlagen (ab 100€) eine hohe Ausfallsicherheit. Eine USV hat natürlich nur einen Sinn, wenn man batteriebetriebene Sensoren und Aktoren betreibt. Wer etwa nur das Licht mit HM schaltet oder die Heizung steuert braucht entweder keine USV oder ein Notstromaggregat fürs ganze Haus.
7. Internet-Schnittstelle (Router)
Die CCU hat eigentlich keine direkte Internet-Schnittstelle. Es braucht immer einen Router oder ein Modem oder Ähnliches um das LAN mit dem die CCU verbunden ist, mit dem Internet zu verbinden.
7.1 Aufgabe
Über eine Internet Schnittstelle kann man von ausserhalb der Reichweite des eigenen LAN/WLAN’s auf die Dienste der CCU zugreifen, etwa um zu kontrollieren, ob die Heizung richtig arbeitet und alle Türen geschlossen sind. Weiters kann die CCU über das E-Mail Addon Mails versenden oder über Internet-Dienste wie Prowl Nachrichten versenden, wenn etwa die Wassermelder eine Überschwemmung melden oder die Alarmanlage scharf geschaltet wurde. Es ist natürlich auch möglich vom Urlaubsort aus via Hotel-WLAN oder Smartphone Mobilfunknetz das WebUI zu öffnen und Einstellungen und Programme an der CCU zu verändern genau so wie man es im heimischen LAN oder WLAN tun würde.
7.2 Standard-Einstellung
Internet Router lassen normalerweise keinen Zugriff von aussen auf Geräte im eigenen LAN/WLAN, wie die CCU zu (große Ausnahme; UPnP, s.u.). Der Zugriff von innen (vom LAN/WLAN) nach aussen (ins Internet) z.B. Zugriff auf einen Zeit-Server oder E-Mail Versand ist aber immer möglich.
Internet Zugang über Meine-Homematic/CloudMatic
Dass der Internet Zugriff von Innen (LAN/WLAN) nach Außen (Internet) normalerweise immer möglich ist macht sich auch der kostenpflichtige „Meine Homematic“ Dienst (nun CloudMatic) zu Nutze (funktioniert ganz ohne Portweiterleitungen, Firewallfreischaltungen, DynDNS Einrichtungen. etc, und vor allem: es funktioniert auch wenn der eigene Internet-Provider keine öffentliche IP-Adresse vergibt, was bei Mobilfunk-Routern meist der Fall ist). Wenn man diesen einrichtet, baut die CCU selbst die Internet Verbindung auf und hält sie aufrecht so lange sie läuft. Will man dann etwa vom Smartphone auf die CCU zugreifen, so verbindet man sich zunächst mit https://<eigene-id>.meine-homematic.de und wird dann vom Dienst mit der bestehenden Internet Verbindung, die die CCU selbsttätig aufgebaut hat „kurzgeschlossen“ und kann so das WebUI bedienen. Das System ist relativ einfach einzurichten, ist aber kostenpflichtig. Da die Verbindung verschlüsselt ist, dürfte die Verbindung sicher sein.
Eine andere Frage ist jedoch, was am Server des Anbieters mit den eigenen Daten bzw. Passwörtern geschieht. Eigene Erfahrungen dazu habe ich nicht. Zu beachten ist auch, dass die CCU gegen Angriffe aus dem eigenen LAN/WLAN ungeschützt bleibt. Es empfiehlt sich daher die CCU Firewall und CCU-Protect des users „blackhole“ zu installieren.
Internet Zugang über öffentliche IP und Port-Weiterleitung
Wenn der eigene Internet-Provider eine öffentliche IP-Adresse vergibt, dann gibt es Alternativen für die Herstellung eines Internet Zugangs zur CCU. Voraussetzung ist eine sogenannte Port-Weiterleitung, die im Router eingerichtet wird. Durch eine Port-Weiterleitung kann eine Anfrage der Form [url]http://<öffentliche-ip-adresse-des-routers>:80[/url] auf [url]http://<ip-adresse-der-ccu>:80[/url] weitergeleitet werden. Wird eine solche IP-Weiterleitung eingerichtet, kann jeder, der die öffentliche IP-Adresse des Routers kennt, von irgendwo im Internet das WebUI der CCU aufrufen.
Dieses ist zwar mit einem (hoffentlich starken) Passwort geschützt, aber die Daten werden unverschlüsselt übertragen und so kann ein „man in the middle“ auch das Passwort bei der Anmeldung mitlesen. Solche „man in the middle“ Angriffe sind etwa in öffentlichen WLANS sehr sehr einfach. Grundsätzlich kann dort jeder mit einfachen Tools den gesamten unverschlüsselten Datenverkehr mitlesen.
Zu beachten ist auch, dass über den Port 80 auch das XML-API läuft , sofern es installiert ist. Es kann ohne Passwort angesprochen werden. Auch die devconig Seite ( via http://<ip-der-ccu>/tools/devconfig.cgi?sid=@12345678@ ) läuft über Port 80. Dazu braucht man aber einen Session-ID, den man aber ein Angreifer wiederum durch Mitschneiden der unverschlüsselten Kommunikation mit dem WebUI leicht herausfinden kann. Über diese Schnittstellen kann ein Angreifer jedenfalls böse Dinge tun.
Auch wenn der Router eine öffentliche IP Adresse hat, so muss diese noch lange nicht fix sein. Meist vergeben Provider bei jedem Neustart eine neue IP Adresse. Manche Provider unterbrechen die Internetverbindung auch regelmäßig von selbst. Das Problem der wechselnden IP Adressen kann man mit einem sogenannnten DynDNS-Provider lösen (z.B. NoIP.com) . Diese bieten einen sogenannten dynamischen DNS Namen an (z.B. myHome.noip.com) , der über ein Kommando (URL) immer wieder mit der jeweils aktuellen IP Adresse verbunden werden kann. Viele Router können das automatisch machen. Wenn die Internet-Verbindung neu aufgebaut ist, teilt der Router dem DynDNS Provider automatisch mit unter welcher IP Adresse das heimische LAN/WLAN momentan erreichbar ist.
Internet Zugang über Teamviewer
Wenn der Router im eigenen LAN/WLAN keine öffentliche IP-Adresse besitzt (also zum Beispiel bei Mobilfunk/UMTS-Routern meist der Fall), dann kann man nicht nur über meine-homematic.de, sondern auch über das Fernwartungsprogramm Teamviewer einen Zugang von außen einrichten. Teamviewer ist für den privaten Gebrauch kostenlos.
Dazu braucht man im eigenen LAN/WLAN einen Computer (PC, Server, Laptop unter Windows, Mac oder diverse Linuxe, auch ein Raspi dürfte funktionieren: http://www.forum-raspberrypi.de/Thread- ... stallieren ), der über das LAN/WLAN Zugang zur CCU hat und laufen muss wann immer man Zugang von außen bereitstellen will. Nennen wir diesen Computer HOME.
- 1. Teamviewer auf HOME installieren. Bei der Installation wird für HOME eine eindeutige Pin/ID vergeben, die man sich merken muss.
2. Teamviewer auf HOME so einrichten, dass er beim Hochfahren automatisch startet (siehe https://www.youtube.com/watch?v=fju2O72IaOQ )
3. Auf dem Gerät mit dem man vom Internet ins eigene LAN/WLAN zugreifen will, nennen wir es REMOTE, muss ebenfalls Teamviewer installiert werden (Windows, Mac, Linux, Android oder iOS sind möglich).
4. Nun kann man über Teamviewer von REMOTE aus den Rechner HOME fernsteuern. Das funktioniert indem man beim Verbindungsaufbau die o.a. Pin/ID eingibt.
Nun zeigt Teamviewer am REMOTE den Desktop von HOME an, den man fernbedienen kann. Also z.B. einen Browser starten und das WebUI der CCU öffnen. Genau so als wenn man am Rechner HOME sitzen würde.
Die Kommunikation zwischen HOME und REMOTE funktioniert so, dass HOME sich zuerst mit einem Teamviewer Server verbindet (da das eine ausgehende Verbindung ist, funktioniert das mit jedem Router) und dort „bekanntgibt“, dass HOME jetzt über den Pin/ID erreichbar ist. Wenn dann REMOTE eine Teamviewer Verbindung startet, verbindet er sich auch mit dem Teamviewer Server und wird dann nach Eingabe des Pin/ID von HOME mit HOME „kurzgeschlossen“. Das Ganze dürfte sicher sein, weil der Datenstrom end-to-end verschlüsselt abläuft und die Fa. Teamviewer ein Unternehmen mit Sitz in Deutschland, seit vielen Jahren am Markt und ium Sicherheit bemüht ist. Näheres dazu https://www.teamviewer.com/docs/de/Team ... ent-de.pdf .
Also vergleichbar mit meine-homematic.de .
UPnP Schnittstelle des Routers
Bei vielen Routern ist standardmäßig UPnP aktiviert. Wenn das der Fall ist, kann ein Server im eigenen LAN/WLAN den Router beauftragen ohne Zutun des Benutzers automatisch eine Portweiterleitung auf sich selbst einzutragen. Die CCU macht das zwar nicht, aber fast alle TCP/IP-Überwachungskameras machen das so und weil Kameras im Smart Home häufig anzutreffen sind, möchte ich hier darauf eingehen.
Man braucht UPnP-fähige Kameras nur ans LAN/WLAN anzuschließen und schon sind sie aus dem Internet bzw. von der super praktischen Smartphone App erreichbar. Ohne dass man was am Router umstellt. In Wahrheit hat die Kamera selbst ein Scheunentor (= Port-Weiterleitung auf einen nicht mit SSL/TLS geschützten Server) geöffnet. Und so ein Scheunentor bleibt im Internet nicht lange unbemerkt (z.B. http://derstandard.at/2000047903830/Web ... ngegriffen).
Unbedarfte User empfinden es als praktisch, wenn man mit dem Smartphone von unterwegs nachsehen kann, etwa wie es dem Hund geht. Problematisch wird es dadurch, dass es offensichtlich sehr viele IP-Kameras mit eklatanten Schwachstellen am Markt gibt, bei denen man über Command Injection auf den in der Kamera eingebetteten Linux-Server zugreifen kann (vgl. https://www.pentestpartners.com/blog/ha ... ra-part-2/).
Damit können Angreifer sich nicht nur ein Bild davon machen wie es dem Hund geht und ob im Haus ein Rembrandt hängt, sondern es kann auch dazu führen, dass die Kamera mit Malware verseucht wird und die eigene Kamera mit ihrem "Mini-Server" von Verbrechern in groß angelegten DDOS Angriffen als Datenschleuder eingesetzt wird (siehe https://en.wikipedia.org/wiki/Mirai_(malware)) und deshalb der eigene Internet Anschluss gesperrt wird.
Offensichtlich sind auch viele Router am Markt, die über das UPnP Protokoll von außen angegriffen werden können (vgl. http://www.t-online.de/computer/sicherh ... en-pc.html).
7.3 Schutzmaßnahmen
Internet Zugang über Meine-Homematic/CloudMatic
Für die Internet Schnittstelle via meine-homematic.de sind mir keine weitergehenden Schutzmaßnahmen bekannt.
Internet Zugang über öffentliche, externe IP und Port-Weiterleitung
Router für lokale Netzwerke lassen standard-mäßig keinen vom Internet eingehenden Netzwerkverkehr auf Geräte im heimischen LAN/WLAN zu, sondern nur ausgehende Requests (und natürlich deren eingehenden Antworten). Es sei denn, dass man im Router eine Port-Weiterleitung aktiviert.
Bei Aktivierung einer Port-Weiterleitung auf die CCU, ist es unbedingt notwendig den Datenverkehr zu verschlüsseln (SSL/TLS Protokoll; Zugriff wie HTTPS://) und den gesamten HTTP Datenverkehr mit Passwort zu schützen. Die Verschlüsselung lässt sich im WebUI aktivieren. Siehe: http://homematic-forum.de/forum/viewtop ... 89&start=8 . Das beschriebene Vorgehen hat jedoch zwei Lücken.
- Die Schnittstelle zur Script-Engine (z.B. http://<ip-adresse>/rega.exe?state=dom.GetObject(%27Alarmanlage%27).State(0) ) oder - falls installiert - auf das XML-API bleibt durch diese Maßnahme ungeschützt weil diese Dienste ohne Passwort erreicht werden können. Die Verschlüsselung nützt wenig, wenn jeder Angreifer ohne Passwort etwa Systemvariablen auslesen und ändern kann.
- Weiters wird beim oben beschriebenen Vorgehen ein unsigniertes Server-Zertifikat erstellt. Das erlaubt es dem Client (z.B. dem Web-Browser am Laptop von dem man vom Internet aus auf die eigene CCU zugreifen will) nicht, zweifelsfrei festzustellen, ob er wirklich mit der eigenen CCU verbunden ist, was insbesondere bei Verwendung einer dynamischen DNS fraglich sein kann. Das bedeutet, dass man bei der WebUI-Passwort-Eingabe nicht sicher sein kann, ob man der heimischen CCU das Passwort eingibt oder gerate einem Angreifer verrät, der den Anmeldedialog simuliert.
- HTTPS ist nicht gleich HTTPS. Wirklich sicher ist nur die TLS 1.2 Verschlüsselung (Ältere Verschlüsselungsprotokolle wie SSL 2 und SSL 3 sind nicht mehr sicher). Mir liegen keine Informationen vor, welche Verschlüsselung eine CCU mit aktivierter HTTPS Schnittstelle unterstützt.
Am Router wird dann eine Port-Weiterleitung nicht auf die CCU sondern auf den Security-Server eingerichtet. Also z.B. von [url]https://<öffentliche-ip-adresse-des-routers>:801[/url] auf [url]https://<ip-adresse-des-security-servers>:802[/url] Am Security Server wird ein Webserver eingerichtet (z.B. Lighttpd oder Apache), der auf Port 802 ausschließlich HTTPS verschlüsselte Verbindungen entgegennimmt, User-ID und Passwort abfragt und dann den Datenverkehr seinerseits im LAN/WLAN auf [url]http://<ip-adresse-der-ccu>:80[/url] weiterleitet. Fpr den Passwortschutz richtet man am Security Server eine htdigest-Authentication ein. Diese sorgt dafür, dass nicht nur das WebUI sondern auch die Script-Engine und das XML-API der CCU nur mit Passwort erreichbar ist.
Damit ist der gesamte Datenverkehr etwa vom Smartphone irgendwo im Internet zum eigenen Router bis zum Security Server sicher und verschlüsselt. Die Strecke im eigenen LAN/WLAN vom Security Server zur CCU ist aber unverschlüsselt und kann daher von Angreifern im eigenen LAN/WLAN ggf. mitgehört werden. Außerdem ist die CCU für Zugriffe aus dem eigenen LAN/WLAN ja sehr offen. Das kann man wie oben beschrieben mit der CCU Firewall und der Lösung CCU-Protect von user „blackhole“ wesentlich verbessern. Dabei erlaubt man jeweils nur dem Security Server Zugriff auf die oben beschriebenen Dienste der CCU.
Damit das auch komfortabel funktioniert, wenn der Provider dem Router immer wieder eine andere öffentliche IP Adresse vergibt, kann man über einen DynDNS Dienst wie oben erwähnt (z.B. noip.com) einen DNS Namen anlegen, über den man immer den eigenen Router bzw. mit Port-Forwarding auch die CCU erreicht. Die URL für eine solchermaßen abgesicherte CCU kann dann aussehen wie https://myHome.ddns.net:801 .
Internet Zugang über VPN Server
Eine Alternative zur Portweiterleitung auf einen Security Server, ist die Einrichtung eines sogenannten "user to site VPN" oder "client to site VPN". Manche Router (z.B. Fritzbox) bieten die Möglichkeit einen VPN Server einzurichten. Das verlangt aber auch eine öffentliche IP Adresse. Auf dem Client (Laptop oder Smartphone etc.) muss man eine dazupassende VPN Client Software installieren (Näheres dazu findet sich zum Beispiel hier: http://www.nwlab.net/tutorials/VPN-FritzBox/). Nimmt man vom Internet aus über den VPN Client mit dem heimischen VPN Server Verbindung auf, so wird verschlüsselt kommuniziert.
Der Client - obwohl irgendwo im Internet - verhält sich dann so, als wäre er mit dem heimischen LAN/WLAN verbunden. Er kann dann etwa über die lokale Internet Adresse der CCU (zum Beispiel 192.168.0.2) per http://192.168.0.2 auf die CCU zugreifen. Der Datenverkehr verläuft dann über die Internet-Strecke durch den VPN Tunnel und ist sicher verschlüsselt, dann wird er unverschlüsselt ins heimische LAN/WLAN weitergeleitet. Der Nachteil: Befindet man sich zum Beispiel mit dem Laptop im Büro, so kann man auf Ressourcen im Firmen-Netzwerk wie zum Beispiel den Drucker im Büro allenfalls nicht zugreifen, solange der Laptop mit dem heimischen VPN verbunden ist. Dieser Nachteil lässt sich bei manchen VPN Lösungen allerdings umgehen indem man eine "split Tunneling" Funktion aktiviert, die nur einen Teil des Netzwerk-Traffics über das VPN leitet. Ein weiterer Nachteil von VPN: Oft ist es nicht möglich auf Firmen PC's den passenden VPN Client zu installieren.
Andererseits kann man über die VPN Verbindung nicht nur auf die CCU sondern auch auf den Drucker zu Hause zugreifen oder das heimische NAS nutzen während die VPN Verbindung aktiv ist. Eben genau so wie wenn man mit dem heimischen LAN/WLAN verbunden wäre. Zu beachten ist auch, dass man - solange man mit dem VPN Server zu Hause verbunden ist - der gesamte Internet Datenverkehr zuerst zum heimischen Router geht und von dort erst zu externen Servern wie etwa http://www.3sat.de/mediathek . Das hat zwei Auswirkungen: Wenn man 3sat schaut wird der heimische Internet-Anschluss belastet (Downloadvolumen? Uploadbandbreite?) und 3sat glaubt man sitzt zuhause. Was etwa im Urlaub bei Netzsperren ein Vorteil sein kann.
Auf einem VServer im Internet, könnte man auch einen VPN Server (OpenVPN) einrichten mit dem sich dann das heimische LAN und ein Client irgendwo im Internet zu einem gemeinsamen VPN verbinden. Das würde zwar auch funktionieren, wenn das heimische LAN/WLAN keine öffentliche IP Adresse hat, ist aber wesentlich aufwendiger als die Lösung via Teamviewer und im Endeffekt wahrscheinlich auch teuerer als die Lösung via Meine-Homematic.de .
Internet Zugang über Teamviewer
Da der HOME Computer ständig laufen muss, ist es wichtig diesen vor unbefugtem lokalem Zugriff während einer Fernbedienungs-Session schützen. Am einfachsten indem man in einsperrt.
UPnP Schnittstelle
Die UPnP Funktion im Router abschalten (siehe http://www.pcwelt.de/tipps/UPnP-abschal ... 17164.html). Möchte man Kamerabilder aus dem Internet ansehen, so sollte man also keine direkte Portweiterleitung auf die Kamera einrichten (egal ob via UPnP oder manuell). Es ist besser auf dem oben beschriebenen Security Server (der nur via HTTPS und Password geschützt erreichbar ist) ein PHP Script zu installieren, das bei Request ein Bild von der Kamera holt und nach außen weiterleitet.
Ob der Router von außen via UPnP angreifbar ist, kann man etwa mit https://www.heise.de/security/dienste/p ... ?scanart=4 überprüfen.
8. Externe Services
Es gibt eine Vielzahl externer Services bzw. Geräten mit verbundenen Services von Drittanbietern, die im Zusammenhang mit einer HomeMatic Installation genutzt werden können. Eine vollständige und genaue Beschreibung ist mir hier nicht möglich, weil ich diese selbst kaum verwende um mein System nicht von Drittanbietern und der Cloud abhängig zu machen. Viele dieser Services sind aber sehr komfortabel und werden daher immer häufiger genutzt. Daher will ich hier einige weiterführende Links auf Seiten angeben, wo meiner Meinung nach Sicherheitsaspekte dieser Services seriös diskutiert werden.
- Alexa - Sprachsteuerung, rbb Bericht: Alexa als Wanze
- CloudMatic - Fernzugriff und Visualisierung
- Doorbird - Türkamera
- Google Home - Sprachsteuerung
- Hue - Lichtsteuerung
- Diverse IP Kameras
- Osram Lightify - Lichtsteuerung
- Sonoff- WLAN Aktoren
- IKEA Tradfri - Lichtsteuerung
Wie oben erwähnt: Über Verbesserungsvorschläge zu diesem Text freue ich mich!
GZI
