Ich werde das sehr oft gefragt, daher ist es mir einen Beitrag wert:
„Wieso wurde mein/e … gehackt? Was hat der/die Hacker/in davon? Es ist ja nur ein kleines Gerät im Internet!“
Die Antwort ist eigentlich ganz einfach, aber schwierig kurz und prägnant zu erklären.
Viele dieser „kleinen“ Geräte, die da gehackt werden – egal ob Antenne, Router, Smartphones oder andere – besitzen ein mächtiges Betriebssystem, und das kann dem Zweck des Hackers nutzen. Es geht also nicht darum, das Gerät vom Netz zu trennen oder die Funktion einzuschränken: es geht darum, Zugrif auf das Gerät zu erlangen und dieses künftig für eigene Zwecke (mit) zu nutzen.
Oft wird die ursprüngliche Funktion des Geräts gar nicht beeinträchtigt – sonst würden die Besitzer ja merken, dass sie gehackt wurden und danach streben, die schadhafte Software zu entfernen. Ist doch praktischer, wenn’s keiner merkt…
Die Geräte werden oft so umprogrammiert (bzw. wird zusätzlich Software installiert), sodass sie auf Arbeitsaufträge („Kommandos“) aus dem Internet horchen und diese dann ausführen. Sie sind dann an sogenannte „Command and Control“-Systeme/-Server angebunden.
Das klingt jetzt noch nicht mächtig, aber wenn man berücksichtigt, dass hunderttausende solcher Geräte, über die Welt verteilt, an so einem System teilhaben, wird klarer, welches Potenzial dadurch entsteht.
Dieses Thema wird sich meiner Einschätzung nach im Zukunft noch zuspitzen: es werden immer mehr Geräte werden ans Internet angebunden und diese werden auch immer leistungsfähiger. Dadurch eignen sie sich immer mehr für solche Aktionen… Man nennt das auch die Ära des Internet of Things (IoT), auf die wir uns rasant zubewegen.
Was kann man dagegen tun? Ein wesentlicher Tipp ist bestimmt, möglichst aktuelle Updates einzuspielen, die häufig Sicherheitslücken beheben, mit denen Angreifer überhaupt die Möglichkeiten bekommen, Zugang zum Gerät zu erlangen und Schadsoftware aufzuspielen. Ansonsten rate ich weiterhin dazu, bewusster zu überlegen, ob wirklich alle Geräte ans Internet angebunden sein müssen bzw. Zugriff darauf haben müssen. Reicht es nicht, wenn zB. Elemente einer Hausautomatisierung mit der Zentrale kommunizieren können? Muss denn jedes Gerät uneingeschränkt mit dem Internet Daten austauschen können?
Mich hat ein aktuelles Ereignis (auch hier sehr gut beschrieben) zu diesem Beitrag inspiriert, außerdem wird dieses Thema nun auch von den Medien verstärkt aufgegriffen und verstanden. In diesem Fall haben hunderttausende Geräte die Kapazität ihrer Internetanbindung genutzt, um die Anbindungen und Bandbreiten großer Webportale lahmzulegen. Das nennt man eine Distributed Denial of Service-Attacke.
Nun möchte ich in der Status-Zeile ein paar Telemetriedaten übermitteln, die vom Raspberry ausgelesen werden. Konkret sind das:
Core Temperatur
Core Spannung
Core Spannung der SDRAM_p
Clock Speeds von Core und ARM
Dazu habe ich ein Script erstellt, das alle 5 Minuten über cron gestartet wird und die vollständige Status-Zeile in der Datei /tmp/aprs-telemetrie.txt hinterlegt. pymultimonaprs versendet dann den Inhalt dieser Datei als Statusmeldung.
Dieses Script (abgelegt als /home/pi/aprs-telemetrie.sh) liest die Werte aus und erstellt die Datei:
Der Raspberry und DVB-T-Stick sind in einem Outdoor-Gehäuse verbaut.
Mit diesem Setup möchte ich einen APRS iGate realisieren, also eine Konfiguration, mit der APRS-Pakete auf der europäischen APRS-Frequenz 144.800 MHz empfangen und dann weitergeleitet werden. Die Weiterleitung soll primär über HAMnet erfolgen und nur im Fehlerfall oder bei nicht-Verfügbarkeit meiner HAMnet-Anbindung direkt ans einen APRS-IS-Tier2-Server (vgl. http://www.aprs2.net/) ins Internet übertragen werden.
Da pymultimonaprs die Messages nicht selbst dekodiert, müssen wir noch multimon-ng installieren:
cd ~
sudo apt-get install cmake
git clone https://github.com/EliasOenal/multimon-ng.git cd multimon-ng mkdir build cd build cmake .. make sudo make install
Installation
Die iGate-Software pymultimonaprs installiere und hole ich von GIT:
cd ~
sudo apt-get install python2.7 python-pkg-resources
git clone https://github.com/asdil12/pymultimonaprs.git
cd pymultimonaprs
sudo python2 setup.py install
Ich habe für meinen Call OE1SCS den Suffix -10, auch SSID genannt, gewählt, der lt. APRS SSID-Erklärung für „internet, Igates, echolink, winlink, AVRS, APRN, etc“ gedacht ist.
Im Eintrag „gateway“ habe ich eine Liste an APRS-IS Gateways eingetragen. Die Liste wird bei jedem Neustart von pymultimonaprs vom ersten Eintrag neu abgearbeitet. Ich habe also die Gateways, die ich bevorzuge, an den Anfang geschrieben. Die meisten iGates besitzen sprechende DNS-Namen. Ich will jedoch nicht von einem funktionierenden DNS-Dienst abhängig sein, daher trage ich die IP-Adressen ein. Damit dort nicht nur kryptische HAMnet-IP-Adressen (beginnen mit 44.) stehen habe, habe ich in der gleichen Zeile den DNS-Namen zusätzlich hinterlegt, zB.: „aprs.oe2xzr.ampr.at:14580“, „44.143.40.90:14580“
Der Dienst versucht 120 Sekunden die APRS-iGates zu erreichen. Nach 120 Sekunden meldet er ein Timeout und probiert den nächsten iGate. Sollte das Netzwerk nicht verfügbar sein oder der iGate-Server am eingestellten Port nicht antworten, wartet pymultimonaprs das Timeout nicht ab, sondern probiert unmittelbar den nächsten iGate in der Liste.
Hier ein Beispiel aus meinem Logfile:
Jan 2 10:53:42 roofpi pymultimonaprs: connecting... 44.225.42.181:14580
Jan 2 10:53:42 roofpi pymultimonaprs: Error when connecting to 44.225.42.181:14580: '[Errno 101] Network is unreachable'
Jan 2 10:53:51 roofpi pymultimonaprs: connecting... 78.47.75.201:14580
Jan 2 10:53:51 roofpi pymultimonaprs: connected
Jan 2 10:53:51 roofpi pymultimonaprs: # aprsc 2.0.18-ge7666c5
Jan 2 10:53:51 roofpi pymultimonaprs: login OE1SCS-10 (PyMultimonAPRS 1.2.0)
Jan 2 10:53:51 roofpi pymultimonaprs: # logresp OE1SCS-10 verified, server T2EISBERG
Jan 2 10:53:51 roofpi pymultimonaprs: sending: OE1SCS-10>APRS,TCPIP*:=4811.4 N/01623.2 E-RXonly APRS iGate
Jan 2 10:53:51 roofpi pymultimonaprs: sending: OE1SCS-10>APRS,TCPIP*:>Raspberry Pi mit RTL Stick
Mittels „append_callsign“: true, gebe ich an, dass mein Call in den APRS-Pfad bei der Weiterleitung ans iGates dazugefügt werden soll.
im Abschnitt „rtl“ wähle ich die Frequenz 144.800 MHz als europäische APRS-QRG, gebe meine Ungenauigkeit des Sticks (26 ppm) an, die ich vorher gemessen habe und wähle einen Gain von 46. Offset-Tuning lasse ich unbenutzt und da ich nur einen DVB-T-Stick am Raspberry habe, lasse ich den device-index bei 0.
im Abschnitt „beacon“ konfiguriere ich die eigene, regelmäßige, Aussendung meiner „Station“:
Ich wähle einen statischen Text für „comment“ und „status„, außerdem übertrage ich im Moment keine Wetter-Informationen. Ich möchte, dass meine Aussendung alle 30 Minuten übertragen wird (30 Minuten * 60 Sekunden = 1800 Sekunden).
Um meine Positionen nicht 100%ig genau im APRS darzustellen, habe ich die „ambiguity“ auf „1“ gesetzt. Das verringert die Genauigkeit meiner GPS-Position um 1/10 Grad-Minute. Dadurch wird meine APRS-Position auf aprs.fi mit dem Hinweis „Position ambiguous: Precision reduced at transmitter by 1 digits, position resolution approximately 185.2 m.“ zB. so dargestellt:
meine Station wird bewusst mit einer Ungenauigkeit von ca. 185 Metern in dem violetten Feld angezeigt. Das Feld weist darauf hin, dass die Position nicht exakt ist.
Damit wäre alles konfiguriert und über das Kommando
/etc/init.d/pymultimonaprs start
habe ich den Dienst gestartet.
Die Funktion kann man über das Logfile /var/log/syslog rasch prüfen. Unmittelbar nach dem ersten Start war meine Station auf aprs.fi sichtbar: http://aprs.fi/info/a/OE1SCS-10
Erfahrungen, Tipps & Tricks
Zuverlässigkeit des USB-Sticks
Ich habe den Dienst einige Tage laufen gelassen. Nach zirka zwei Tagen habe ich folgende Fehlermeldung im Logfile gehabt. Auch über „dmesg“ war das Problem sichtbar:
Dec 30 21:23:34 roofpi kernel: [ 2139.021653] usb 1-1.3: usbfs: usb_submit_urb returned -121
Dec 30 21:23:34 roofpi kernel: [ 2139.022123] usb 1-1.3: usbfs: usb_submit_urb returned -121
Dec 30 21:23:34 roofpi kernel: [ 2139.022580] usb 1-1.3: usbfs: usb_submit_urb returned -121
Dec 30 21:23:34 roofpi kernel: [ 2139.023041] usb 1-1.3: usbfs: usb_submit_urb returned -121
Dec 30 21:23:34 roofpi kernel: [ 2139.023968] usb 1-1.3: USB disconnect, device number 4
Dec 30 21:23:34 roofpi kernel: [ 2139.260292] usb 1-1.3: new high-speed USB device number 6 using dwc_otg
Dec 30 21:23:34 roofpi kernel: [ 2139.372309] usb 1-1.3: New USB device found, idVendor=0bda, idProduct=2832
Dec 30 21:23:34 roofpi kernel: [ 2139.372335] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Dec 30 21:23:34 roofpi kernel: [ 2139.372353] usb 1-1.3: Product: RTL2832U
Dec 30 21:23:34 roofpi kernel: [ 2139.372369] usb 1-1.3: Manufacturer: Generic
Dec 30 21:23:34 roofpi kernel: [ 2139.372386] usb 1-1.3: SerialNumber: 77771111153705700
Es hat sich also der USB-Stick verabschiedet „usb 1-1.3: USB disconnect, device number 4“ und sofort wieder neu verbunden. Damit war natürlich ein Neustart des pymultimonaprs nötig, damit dieses wieder korrekt lauscht. Leider war es damit nicht getan und der Fehler ist wenige Minuten später wieder gekommen. Ich habe das ein paar Mal wiederholt und schon befürchtet, dass der Stick vielleicht kaputt ist. Ein Reboot hat die Situation aber entschärft und nun läuft der Stick wieder seit 2 Tagen stabil.
APRS-Meldungen der ISS
Mit einem einfachen Hack, der unter anderem hier beschrieben wird, soll es möglich sein, neben der primären APRS-Frequenz 144.800 MHz auch die APRS-Frequenz der Raumstation ISS zu empfangen. Diese sendet auf 145.825 MHz. Natürlich können diese Meldungen nur gehört werden, wenn sich die ISS in Reichweite befindet. Es gibt zahlreiche Webseiten im Internet, mit denen der Zeitpunkt der nächsten Überflüge der ISS am eigenen Standorts berechnet werden kann.
Leider hat sich dieser Hack bei mir nicht bewährt: mein Stick schafft es kaum noch APRS-Meldungen zu decoden, wenn er auf beide Frequenzen hört. Die Qualität nimmt rapide ab. Woran es genau liegt, kann ich schwer sagen. Ich habe aber die Vermutung, dass es am Squelch liegt, der bei dieser Konfiguration genutzt werden muss: das Programm rtl_fm, das dem Empfang der Pakete übernimmt, funktioniert ohne Squelch, sofern man nur auf einer QRG hört. Wenn man mehrere QRGs angibt (144.8, 145.825, …) muss ein Squelch-Wert angegeben werden. Ich habe zwar 1 als kleinsten möglichen Wert konfiguriert, vermute aber, dass der Squelch bei APRS-Paketen zu spät reagiert und daher viele Pakete nicht vollständig gehört werden. Sobald ich nur auf 144.8 ohne Squelch höre, empfange ich wieder viel mehr Pakete und alles scheint zu funktionieren.
pymultimonaprs kann auch Wetterdaten mitsenden. Ich habe leider keine Wetterstation, möchte aber Telemetriedaten meines Raspberry Pi 2 übermitteln. Dazu kann man ein JSON-File erstellen, das diesem Format entspricht (Quelle: https://github.com/asdil12/pymultimonaprs/blob/master/README.md):
You can set weather to a json-file. eg: "weather": "/path/to/weather.json",
If you don’t want do send weather date, just leave it on false. This will be read in like the status-file and can look like that:
timestamp is seconds since epoch – must be included
wind
speed is in km/h
direction is in deg
gust is in km/h
temperature is in °C
rain
rainlast1h is in mm
rainlast24h is in mm
rainmidnight is in mm
humidity is in %
pressure is in hPa
The timestamp must be included – everything else is optional.
Meine Idee wäre, die Temperatur & Spannung des Raspberry Core zu übermitteln, die mittels des Kommandos „vcgencmd“ ermittelt werden können. Details siehe hier: http://elinux.org/RPI_vcgencmd_usage
Ich müsste also ein JSON-File erstellen, in das ich
Für die Spannungen ist kein Feld in den Wetterdaten vorgesehen. Man könnte diese Daten also über die „status„-Aussendung übermitteln. Dazu ändert man im Konfig file (/etc/pymultimonaprs.json) im Bereich „status“ folgendes:
AP510 mit SmartBeaconing, zu Fuß + mit Straßenbahn unterwegs
SmartBeaconing ist eine gute Idee: statt per APRS seine Position alle x Sekunden auszusenden und damit das APRS-Netz unnötig zu belasten, wird die Position nur gesendet, sobald es das System „smart“ findet: bei Richtungsänderungen, wesentlichen Geschwindigkeitsänderungen, etc.
Das entlastet das Netz hinsichtlich der Anzahl an Meldungen, die direkt oder über Digipeating übertragen werden und erhöht die Wahrscheinlichkeit für andere Benutzer, dass Airtime für deren Aussendung frei ist.
AP510 im Rucksack in der Straßenbahn (Antenne ist hier testweise eine Nagoya NA-771)
Ich habe überall SmartBeaconing verwendet. Schließlich bin ich großteils im Stadtgebiet von Wien und in der näheren Umgebung unterwegs und dort ist die Dichte an APRS-Empfängern & -Digipeatern sehr hoch.
AP510 APRS Tracker am Boot auf der Adria bei Kroatien im Juni 2015
Leider hat sich SmartBeaconing für mich nicht bewährt: obwohl ich mit 5 Watt über eine externe Magnetfußantenne (Nagoya UT-106UV) vom Autodach aus sende, werden nur 30-40% meiner Meldungen aufgenommen. Und das reicht nicht, um die Strecke annähernd korrekt abzubilden. Vor allem, wenn eine Richtungsänderung nur alle 1-2 Minuten passiert, hinterlasse ich nur alle 5 Minuten einen Punkt auf der Map bei dieser schlechten Erfolgsquote der Übertragung.
Ich habe daher SmartBeaconing deaktiviert und sende im Moment stur alle 30 Sekunden. Damit bekomme ich ausreichend Übertragungen zusammen, um die Route gut abzubilden. Gleichzeitig ist mir bewusst, dass dadurch das Netz stärker belastet wird. Da ich aber nicht viel mit dem Auto unterwegs bin, denke ich, dass es zumutbar ist
APRS Strecke mit Argent OpenTracker USB ohne SmartBeaconin
Vor einigen Monaten habe ich mir ein SainSonic AP510 um knapp € 100,- über eBay aus DL gekauft. Ich bin total begeistert! Vielleicht ausnahmsweise mal weniger, weil es etwas Bestimmtes so gut kann. Sondern diesmal weil es so viel kann.
Das Ding wird als „APRS Tracker VHF GPS Bluetooth Thermometer TF Card APRSdroid“ angepriesen. Man sieht schon: da steckt viel drinnen.
Ursprünglich dachte ich, ich kaufe einen APRS Tracker. Ich war froh, dass ein leistungsfähiger Akku (angeblich 3.300mAh LiPo) drinnen ist, der auch wirklich 2 Tage hält, und dass ich kein separates Funkgerät brauche (mit komplizierten und herstellerspezifischen Adapterkabeln), sondern ein Transceiver mit 1 Watt (manche behaupten 1,5 Watt) für VHF (2 Meter-Band) mit drinnen ist.
Auspacken & Inbetriebnahme
Ich möchte da ja nicht zu sehr auf andere Blogger verweisen. Aber lest mal, was die alles erlebt haben! Ich kann das großteils auch bestätigen, aber die zentrale Aussage bleibt: auspacken und gleich mal ein Firmware Upgrade machen. Damit erspart ihr euch diese Erfahrungen und mit der Firmware aus Oktober 2014 funktioniert das Gerät bei mir sehr gut.
Meine Erfahrungen habe ich mit der Software vom 8.10.2014 (20141008) gemacht. Generell kann ich den Thread des Herstellers empfehlen. Die Seite ist zwar 95% chinesisch, aber die Downloads sind zu erkennen und selbsterklärend: http://www.y027.com/dvbbs8/dispbbs.asp?boardid=5&Id=829
Falls das Update-Programm nach dem Start alles chinesisch darstellt, habe ich einen einfachen Trick gefunden: im Verzeichnis des Programms gibt es eine Datei „avrubd.ini“. Öffnet diese mit einem Texteditor und sucht im obersten Block „[last]“ nach „language“ und ändert diese auf „English“:
language=English
Ein paar Dateien werden für den Start der Programme benötigt, zB. mscomm32.ocx oder msstdfmt.dll. Diese Dateien findet ihr im Internet oder auf der Seite eines anderen Bloggers.
In der Version von Oktober 2014 hat sich das Konfigurationsprogramm einwandfrei bedienen lassen.
Die Einstellungen sind weitgehend selbsterklärend. Folgende Punkte möchte ich kurz beschreiben:
MIC-E aktiviert die Komrimierung der APRS-Daten. Ich habe damit in OE, S5, HA und 9A keine Probleme gehabt. Die Übertragungsdauer wird durch diese Funktion reduziert.
Smart beaconing: das ist ein lobenswertes Feature, mit dem nicht ununterbrochen periodisch Nachrichten gesendet werden, sondern Meldungen erst dann geschickt werden, wenn sich meine Fahrtrichtung ändert.
Busy-control: damit hört der AP510 kurz in den Kanal, ob dieser frei ist, bevor die eigene APRS-Aussendung beginnt.
Erfahrungen
AP510 im Rucksack in der Straßenbahn (Antenne ist hier testweise eine Nagoya NA-771)
In den nächsten Tagen habe ich das Gerät überall mitgenommen. Zum Testen natürlich.
SainSonic AP510 im Zug mit Antenne Diamond RH951S
Meine Positionsmeldungen wurden großteils gut übertragen, ich habe allerdings in Gebäuden (auch direkt hinter (vmtl. bedampften) Fenstern) oft keinen GPS Fix bekommen.
Im vorigen Beitrag habe ich für diesen Blog ein Zertifikat von Let’s encrypt! erstellt. Dieses ist 3 Monate gültig. Es ist vorgesehen, dass das Erneuern des Zertifikats automatisch passiert.
Konkret werde ich einen Cronjob erstellen, der monatlich ein neues Zertifikat mit Hilfe des „letsencrypt-auto“ Python-Script bezieht.
Konfiguration
Um mir eine Menge Kommandozeilenoptionen zu ersparen, erstelle ich eine Konfigurationsdatei /etc/letsencrypt/cli.ini, die meine Standardwerte enthält:
rsa-key-size = 4096
text
redirect
renew-by-default
agree-tos
email = meine.email@adresse.at
Hier sind die Parameter kurz erklärt:
rsa-key-size
entweder 2048 (Standard) oder sicherer mit 4096 Bit. Ich möchte meine Zertifikate mit 4096 Bit RSA erstellen.
text
nur im Text-Modus starten (ohne Menüführung). Schließlich soll der Client automatisch im Hintergrund funktionieren.
redirect
ich wurde immer gefragt:
Please choose whether HTTPS access is required or optional.
-------------------------------------------------------------------------------
1: Easy - Allow both HTTP and HTTPS access to these sites
2: Secure - Make all requests redirect to secure HTTPS access
-------------------------------------------------------------------------------
Select the appropriate number [1-2] then [enter] (press 'c' to cancel):
Um diese Frage vorab zu beantworten, fügt man entweder die CLI-Option „–redirect“ an, oder eben in der cli.ini den Ausdruck „redirect“. Damit wird die Option 2 gewählt: make all requests redirect to secure HTTPS access.
renew-by-default
Erneuert das Zertifikat standardmäßig.
agree-tos
Damit stimmt man den Regeln von let’s encrypt! zu. Schließlich wollen wir den Vorgang ja per Cronjob automatisieren und nicht die Regeln manuell bestätigen müssen.
email
Die Email-Adresse, mit der ich bei let’s encrypt! registiert bin.
Damit bekomme ich jedes Monat am 20. Tag das Zertifikat erneuert. Da derzeit das Zertifikat für 90 Tage gültig ist, bin ich damit auf der sicheren Seite und habe immer ein Zertifikat, das maximal 31 Tage alt ist.
SSL-Zertifikate für Webserver nach dem Standard X.509 haben – kurz gesagt – zwei Aufgaben:
sie verschlüsseln die Verbindung zwischen Webserver und Client bzw. Browser am Client (Internet Explorer, Firefox, Chrome, Safari, …). Das ist erkennbar am https:// zu Beginn einer Webseitenadresse.
sie bestätigen, dass der aufgerufene Webdienst zu der Organisation gehört, die man aufgerufen hat. Das ist zB. beim Online Banking wichtig. Da will man ja wirklich nur bei der eigenen Bank einloggen und die Kennworte eingeben und nicht auf einer Fishing-Seite, die vorgibt, die Seite der Bank zu sein und in Wirklichkeit die Zugangsdaten an Betrüger übergibt.
Bisher habe ich meine SSL-Zertifikate für Webserver über CACert erhalten. Damit diese ohne Warnung bzw. Fehlermeldung von den Clients/Browsern akzeptiert werden, muss man jedoch erst manuell dem Root-Zertifikat von CACert vertrauen. Nur wenige Distributationen, zB. Debian, vertrauen CACert standardmäßig.
Der neue Internet-Dienst Let’s Encrypt bietet kostenlose SSL-Zertifikate an, die von gängigen Browsern akzeptiert werden. Seit 3. Dezember 2015 ist dieser Dienst in einer Public Beta Phase und kann nun von jedermann genutzt werden.
Besonders spannend finde ich, dass Let’s Encrypt einen Client bereitstellt, mit dem die Zertifikate erzeugt/beantragt werden und der sie auch gleich im Webserver installiert. Die gängigen Methoden über Certificate Signing Requests (CSR) werden nicht angeboten.
Das Ziel
Um den neuen Dienst auszuprobieren, möchte ich meinen WordPress-Blog, der aktuell unter http:// und https:// (mit CACert-SSL-Zertifikat) erreichbar ist, nur mehr über https:// anbieten und mit einem Let’s Encrypt-Zertifikat versehen.
Die Standard-URL meines Blogs ist derzeit http://, also unverschlüsselt. Das möchte ich auch ändern und somit in Zukunft den Inhalt nur mehr verschlüsselt ausliefern.
Let’s go!
Mein Blog läuft unter Ubuntu 14.04 LTS. Hier muss ich zuerst „git“ installieren, damit der letsencrypt-Client geladen werden kann:
Danach kann ich ins Verzeichnis „letsencrypt“ wechseln und dort das Programm „letsencrypt“ mit dem Parameter „auto“ ausführen. Mein Webserver (apache) ist ein häufig verwendeter Webserver und sollte vom Programm erkannt werden:
cd letsencrypt/
./letsencrypt-auto
Es erscheint ein praktisches ncurses-geführtes Menü, das nach der Webseite bzw. dem Domainnamen fragt, für den ein Zertifkat erstellt werden soll. Der Dienst hat also meine Konfiguration korrekt erkannt:
Nach der Bestätigung, werde ich nach meiner Email-Adresse gefragt:
Hier erhalte ich leider eine Fehlermeldung: „There seem to be a problem with that address.“. Ich habe das leider nicht lösen können. Lt. Recherche im Internet wird überprüft, ob zu der Email-Adresse entsprechende MX bzw. A-Records bei DNS eingerichtet sind. In meinem Fall gibt es gültige MX-Records. Trotzdem akzepiert letsencrypt die Adresse nicht. Es gibt zwei Möglichkeiten fortzusetzen;
entweder man startet den letsencrypt-Client mit dem Parameter –register-unsafely-without-email oder
ich verwende eine andere Email-Adresse.
Da in Foren davon abgeraten wird, keine Email-Adresse anzuführen, habe ich einfach eine GMX-Adresse von mir genutzt. Damit war das Problem „gelöst“.
Im nächsten Schritt hat mich der letsencrypt-Client gefragt, ob ich in der Webserver-Konfiguration auch http-Verbindungen zulassen möchte, oder nur https. Die Varianten heißen „Easy“ und „Secure“. Ich habe ja als Ziel im Auge, alle Verbindungen mit dem Zertifikat zu versehen, also habe ich „Secure“ gewählt:
Und schon kommt die Meldung, dass letsencrypt fertig ist:
Ich habe sofort die Webseite in meinem Browser neu geladen und sofort das letsencrypt-Zertifikat gesehen. Die Seite wurde ohne Fehler angezeigt.
Der letzte Schliff in WordPress
Weil mein Blog bisher über http:// angeboten wurde, habe ich im WordPress Backend die Hauptadresse und Webseiten-Adresse angepasst und von https://stefan.schultheis.at auf https://stefan.schultheis.at geändert:
Um sicher zu gehen, dass keine Inhalte mehr über http geladen werden, habe ich ein WordPress Plugin installiert: Easy HTTPS (SSL) Redirection. Dieses Plugin sendet bei http-Aufrufen ein Redirect (http 301, Moved Permanently) zu https. Damit stelle ich sicher, dass künftig alle Aufrufe über https beantwortet werden.
Die Konfiguration des Plugins war wirklich einfach. Ich habe die „Automatic redirection to the HTTPS“ aktiviert und für „The whole domain“ gewählt. Weiters erzwinge ich https mittels „Force resources to use HTTPS URL“:
Es gibt eine Warnung, die am Screenshot oben rot sichtbar ist, was zu tun wäre, wenn es zu Problemen kommt. Diese Warnung habe ich ignoriert, ich hatte auch keine Probleme nach der Aktivierung.
Prüfung des Zertifikats
Ab sofort ist mein Blog also unter https:// erreichbar. Wenn man mit http:// aufruft, wird man sofort mittels 301-Redirect auf die verschlüsselte Version verwiesen.
Das Zertifikat wird in Firefox (Version 42.0) problemlos angezeigt:
Das Zertifikat ist als 2048 Bit RSA mit SHA-256 und Gültigkeit von 3 Monaten sichtbar:
Die Zertifkatskette zeigt „DST Root CA X3“ als Stammzertifizierungsstelle, danach die „Let’s Encrypt Authority X1“:
Nach der Installation des Zertifikats empfiehlt übrigens auch Let’s Encrypt, dass man die Konfiguration mittels eines Gratisdiensts von Qualys SSL Labs prüft: https://www.ssllabs.com/ssltest/
In meinem Fall habe ich Grade A bekommen, also die Bestnote. Das spricht für die saubere Implementierung durch den Let’s Encrypt Client und für eine saubere Konfiguration der Sicherheitseinstellungen des Webservers:
Der Qualys-Test überprüft eine große Anzahl an Werten und Konfigurations-Einstellungen. Unter anderem beispielsweise die angebotenen Verschlüsselungsstärken, die Konfiguration von Perfect Forward Secrecy, die Kompatibiltät zu Endgeräten und Browsern uvm.
Falls bei euch hier Einschränkungen angezeigt werden, helfen vielleicht die Empfehlungen von bettercrypto.org. Dort findet ihr ein „Paper“, in dem für zahlreiche gängige Webvserver Konfigurationen empfohlen werden, um die Sicherheit zu verbessern und unsichere Methoden zu beseitigen. Ich gehe mittlerweile bei der Installation von neuen Webserver immer nach deren Anleitung vor, auch beim gegenständlichen Blog.
Mein Fazit
Die Installation war super-einfach und hat super funktioniert, bis auf meine Email-Adresse, die vom Client nicht akzeptiert wurde (wie oben beschrieben). Da diese Email-Adresse aber sowieso nicht im Zertifikat zu sehen ist, sehe ich da kein großes Problem – Hauptsache, es ist eine gültige Email-Adresse verknüpft. Der übrige Teil der Installation und das Zertifikat selbst waren einwandfrei.
Für mich stellt sich noch eine Frage: vertraue ich dem Zertifikat für sensible Kommunikation?
Hier bin ich noch vorsichtig. Vielleicht bin ich zu Paranoid und es ist hier gar nicht angebracht, aber die bisher gängige Methode mittels CSR war mir schon sympathisch. Der private Schlüsselteil ist dabei nämlich immer bei mir geblieben. Ich vermute, dass auch bei Let’s Encrypt der private Teil des Schlüssels meinen Server nicht verlässt. Auch aufgrund der Tatsache, dass der Quellcode des Programms offen ist (Open Source) und jeder im Internet überprüfen kann, was bei der Installation genau passiert.
Trotzdem: ich werde Let’s Encrypt auf meinen Webseiten verwenden, die für die Öffentlichkeit gedacht sind. Auf Webseiten, die private und schützenswerte Inhalte liefern (zB. OwnCloud oder VPNs) werde ich wohl derweil noch bei selbstsignierten Zertifikaten bleiben oder CACert nutzen, wo man über CSR die Zertifikate beantragt.
Mit großer Freude habe ich gelesen, dass seit 23. August 2015 auch ein Unifi-Modul für fhem verfügbar ist! (Das Changelog sagt: „added: 74_Unifi.pm for the Ubiquiti Networks (UBNT) – Unifi Controller“)
Das muss ich gleich probieren! Einen Unifi-Controller habe ich laufen, jetzt möchte ich diesen mit fhem verbinden und anhand der Clients im WLAN die Anwesenheitserkennung von fhem nutzen.
Mittlerweile habe ich den Unifi Controller in Version 4.6.6 bei mir laufen. Von Version 3 zu Version 4 hat sich einiges geändert, auch in der Unifi API. Es ist daher verständlich, dass man die Versionnummer angeben muss. Gleichzeitig ist es toll, dass das fhem-Modul sowohl Version 3 als auch Version 4 unterstützt.
Ich habe für den Unifi-Zugriff aus fhem einen eigenen User „fhem“ mit „Read Only“-Berechtigung im Unifi Controller angelegt.
Der Zugriff von fhem war mit einer Zeile erledigt:
Ich habe dennoch alles explizit angegeben. Damit hoffe ich, dass in zukünftigen Versionen keine Problem auftauchen (zB. sobald es Version 5 gibt, etc.).
Zuerst habe ich den angezeigten Namen vom Unifi-Controller meiner Site als siteID anzugeben. Damit habe ich keine Werte bekommen. Nach kurzer Suche habe ich die Fehlermeldung im Log gefunden:
myunifi (Unifi_GetClients_Receive) - Failed! - state:'error' - msg:'api.err.NoSiteContext' - This error indicates that the <siteID> in your definition is wrong. Try to modify your definition with <sideID> = default.
Folgender Hinweis hilft: in der URL des Controller sieht man, mit welcher siteID man verbunden ist, auch wenn diese einen anderen Namen trägt, der im Controller angezeigt wird:
Es hat dann sofort funktioniert: im „Unsorted“-Bereich habe ich nun das Objekt myunifi und alle verbundenen Endgeräte:Die Daten, die fhem vom Unifi Controller bezieht sind umfangreich und ermöglichen viele Anwendungen, auch außerhalb der Presence-Funktion. Hier die Details zu einem Client:
Jetzt kann ich dank fhem und des Edimax 2101W den Stromverbrauch meiner Haushaltsgeräte messen. Und begonnen habe ich, wie ihr wisst, mit der Nespresso Kaffemaschine:
Die obere Grafik zeigt jeweils den Monatsverbrauch in kWh. Die untere Grafik zeigt den jeweils aktuellen Stromverbrauch in Watt. Die Granularität ist 30 Sekunden.
Hier eine detailliertere Ansicht (gezoomt):
Was können wir aus diesen zwei Grafiken ableiten:
das Aufheizen der Maschine benötigt weniger als 1 Minute und „zieht“ 1100-1200 Watt
für das Halten der Temperatur benötigt die Maschine immer wieder bis zu 400 Watt
wenn ich mir einen Kaffee mache, zeigt der Edimax 2101W kurz 45 Watt an, ich vermute hier die Pumpe, etc
Daraus ergibt sich in kWh:
für’s Aufheizen verbraucht die Maschine etwa 0,003-0,005 kWh (= 3-5 Wh)
inkl. Aufheizen und einer Stunde Betrieb verbraucht die Maschine zirka 0,016 kWh (16 Wh)
für jede weitere Stunde verbraucht die Maschine 0,0091 kWh (= 9,1 Wh
Ich wollte immer schon wissen, wieviel Energie die Geräte im Haushalt verbrauchen. Waschmaschine, Kaffeemaschine beim Aufheizen, Computer, SAT Receiver, meine Funkfeuer-Installation am Dach, etc… Anwendungsbereiche hätte ich viele.
Ein Energiemessgerät mit Anzeige oder Logger auf SD-Karte hat meine Ansprüche nicht ganz zufriedengestellt. Natürlich möchte ich die Daten automatisch und zeitnah auslesen und darstellen.
Toll, dass das nun möglich ist und dass es sich in FHEM, meiner zentralen Software für die Hausautomatisierung, einbinden lässt.
Einrichtung
Heute Früh hat die Post meinen Edimax 2101W, gekauft um knapp weniger als € 50,-, zugestellt. Es handelt sich dabei um einen Zwischenstecker für Steckdosen, der per WLAN verbunden ist und über eine Android-App geschaltet (ein/aus), konfiguriert (Zeitschaltfunktionen, WLAN-Zugangsdaten) und ausgelesen (Energieverbrauch) werden kann.
Das Gerät sendet nach dem Anstecken an einer Steckdose eine SSID als Master (Access Point) aus. Ich verbinde mich mit meinem Android Tablet zu dieser offenen SSID, starte die EdiMax-App und konfiguriere die SSID und das Kennwort für mein WLAN, damit der Edimax 2101W sich nach einem Reboot in mein Hausnetz integriert. Meinem DHCP-Server am Router habe ich eine feste IP-Adresse für die MAC-Adresse des Edimax Gerätes eingestellt, damit sich diese nicht ändert und ich per Hausautomatisierung das Gerät abfragen kann.
Einbindung FHEM
In FHEM gibt es seit ein paar Wochen ein fertiges Modul für die Einbindung des Edimax 2101W. Es ist nicht mehr zu tun, als das Gerät mit einem einzeiligen Kommando einzubinden:
define SmartPlugCpower EDIPLUG 192.168.1.23
FHEM nimmt nun für die Authentifizierung die Standardwerte admin/1234 an und liest sofort alle Daten aus:
Für die Verbesserung der Darstellung (va. am Floorplan) habe ich noch folgende Zeilen konfiguriert:
im Diagramm die Sources der ersten Zeile auf „Verbrauch Watt“ geändert
statt der standardmäßigen Regex auf SmartPlugCpower.power_now geändert, weil das der Wert ist, den ich sehen will.
Durch Klicken auf „Write .gplot file“ wird die Einstellung aktiviert und eine Grafik erstellt.
Für die Monatsgrafik habe ich die gleichen Zeilen angepasst, die Einheit ist allerdings „kWh“:
Ich mach‘ mir mal einen Kaffee
Ich hab‘ also einmal die Nespresso Kaffeemaschine angeschlossen und mir zwei Espressi gemacht:
Nach dem Einschalten beim Aufzeihen der Maschine werden kurz immerhin 1.200 Watt benötigt:
2015-07-16_06:49:43 SmartPlugCpower ON / 1201.70 W / 5.3106 A
Auch zwischendurch heizt die Maschine immer wieder kurz nach und hat in 1,5 Stunden (aufzeihen, zwei Espressi + 1,5h Leerlauf, danach abgeschaltet) immerhin 0,031 kWh verbraucht.
Diese Website verwendet Cookies, damit wir dir die bestmögliche Benutzererfahrung bieten können. Cookie-Informationen werden in deinem Browser gespeichert und führen Funktionen aus, wie das Wiedererkennen von dir, wenn du auf unsere Website zurückkehrst, und hilft unserem Team zu verstehen, welche Abschnitte der Website für dich am interessantesten und nützlichsten sind.
