Wer mit CustomROM w.z.B. LineageOS „herumspielt“ ist ja bekanntlich des öfteren mal von totalem Datenverlust bedroht. Insbesondere wenn der „DailyDriver“ davon betroffen wurde, reift der Wunsch nach einem eigenen sicheren Datentresor, der eben nicht nur die Daten vor Verlust bewahrt sondern auch jede komplette Neuinstallation, mehr oder weniger, zu einem kurzen Prozess ohne viel Schmerz macht. Und ohne seine Daten vorher in nur vermeintlich vertrauenswürdige fremde Hände zu geben.
Welche Möglichkeiten es gibt, und die dazu passenden Anleitungen, findet mensch haufenweise im Netz. Aber wie z.B. ein Backup nur dann ein Backup ist, wenn sichergestellt ist, dass die Wiederherstellung funktioniert, ist ein Datentresor nur dann ein Tresor wenn sichergestellt ist, dass die Tür geschlossen ist und das Schloss funktioniert … und der Tresoreigentümer sofort erfährt wenn es nicht so ist.
Wer also seine Daten sicher verschlossen hat sollte sich, wie im realen Leben auch, umgehend einen pflegeleichten aber zuverlässigen Wachhund zulegen. Wenn der dann nicht nur Einbrecher sondern auch offene Türen und kaputte Schlösser erkennt und meldet, und nix kostet … ist eigentlich alles perfekt? ;o)
Selten. Denn kostenlose Wachhunde gibt es zwar sehr viele. Aber entweder sind die nicht sehr pflegeleicht, oder uralt, oder riesengroß … oder fressen jedem Besucher aus der Hand ohne das man das mitbekommt.
Entscheidend ist also nicht nur WIE ein Problem gelöst wird sondern auch WOMIT.
WOMIT bedeutet nicht nur schlank und erprobt und sicher und pflegeleicht … sondern auch zukunftssicher. Und da landet interessierter mensch ziemlich schnell bei Dingen wie „IoT“ und „MQTT“ … der neue heiße Sch*ss für jeden Nerd, und alle die gerne einer wären!? ;o)
Wer dann allerdings im Internet spazieren geht und sich anguckt was manche dort teilweise für vermeintliche „Tresore“ hingestellt haben, bekommt das kalte Grausen. Gerade mit IoT und MQTT!
Dazu zählen insbesondere Anwendungen, die sich als „neuer heißer Sch*ss“ präsentieren, aber Techniken aus dem vorletzten Jahrhundert verwenden.
Bei Tests mit einem sehr gut abgesicherten host gab es letztlich nur einen einzigen mqtt-Client für Android, der mit diesem kommunizieren wollte. Alle anderen waren nicht in der Lage eine Verbindung aufzubauen, weil (heutzutage[!]) unsichere Verbindungen vom server abgelehnt wurden. Glücklicherweise ist das genau einer der Clients die sich sehr gut für die Lösung unseres „Problems“ eignen.
Wer als erprobter Zuhause-Admin oder interessierter Laie einen Tresor aber keinen brauchbaren Wachhund hat, sollte hier also durchaus weiterlesen.
Der Anfang
Als erstes brauchen wir für unseren sicheren server natürlich einen sicheren host. Wer IoT ins Intranet einsperrt (und denkt das muss so sein), oder einen Provider nimmt „weil der sich um Sicherheit kümmert“ ist erst einmal schon, mehr oder weniger auf dem Holzweg. Ein Admin, dem nur in den heimischen Hallen die Probleme des Tages mitgeteilt werden können, hat noch nix von qualifizierter Sorgearbeit gehört!? ;o)
Und wer andererseits Löcher in die heimische Firewall bohrt damit seine Sorgenkinder sich bei ihm jederzeit melden können, riskiert nicht nur Bohrstaub sondern insbesondere neugierige Nachbarn und „Leute, die nur mal schnell irgendein Zeugs zwischenlagern“ wollen?
Letztlich gilt wie schon vor 500 Jahren: sicher lebt nicht der Ritter auf der Burg, der Angst haben muss vor seiner eigenen Torwache, sondern der Diplomatieerfahrene, der Zusammenhänge erkennt und entsprechend vorsorgt. Und bei Erfolg dann auch mal nackt auf dem Felde stehen kann.
In diesem Sinne ist IoT/MQTT nur so sicher wie der host eben Sicherheit bieten kann. Und der sollte unabhängig von IoT oder anderen Diensten sicher sein. Deshalb sei auch hier nochmal dringend ans Herz gelegt, mit Experimenten wie IoT im Internet erst zu starten wenn grundlegende Sicherheit gewährleistet ist. Da gibt es herrliche Helferlein w.z.B. SSLLabs, die die eigenen Ports auditieren, oder wie Mozilla, die bei der Konfiguration von Apache und OpenSSL behilflich sind. Sinnvoll eingesetzt sind auch Dinge wie Fail2ban durchaus hilfreich.
Und dann fällt uns natürlich auf: für einen sicheren server und einen sicheren host brauchen wir natürlich einen server/einen host!? Da sind also alle die „nur“ Webspace oder sogar SaaS nutzen, schon mal Außen vor? Denn Voraussetzung für „selbst in die Hand genommene Sicherheit“ ist natürlich der root-Zugang. Ob dediziert oder virtuell oder sogar als Cloud ist da nicht ganz so wichtig.
Aber da „Draußen“ im überwiegenden Teil unseres Universums gleichzeitig „Drinnen“ bedeutet, kann es natürlich trotzdem den einen oder anderen Weg geben, auch ohne root-Zugang am neuen heißen Sch*ss teilnehmen zu können? Gibt es vielleicht schon mqtt-Plugins für Forensoftware?
Der erste Schritt
Um schnell und zuverlässig und ohne riesigen Aufwand Überwachungsinformationen übertragen zu können bietet sich heute das schon erwähnte mqtt-Protokoll an. Das ist für kleine und kleinste Geräte gedacht und somit intellektuell anspruchslos, halbwegs energiesparsam und entkoppelt alle Beteiligten, so das letztlich jeder nach seiner Fasson leben kann und trotzdem die Kommunikation funktioniert.
Passende mqtt-Server gibt es in einer schier unüberschaubarer Menge. Sehr häufig eingesetzt wird der mosquitto-server, der sich auch auf schmalbrüstigen Hosts kaum in die Knie zwingen lässt. Inklusive kommen dort auch ein Publisher und ein Subscriber für die Kommandozeile mit, die sich prima in Scripte einbauen lassen.
Ist der mqtt-Server installiert und getestet und abgesichert (ein geschlossener Port 1883, aktive Benutzerrechteverwaltung und die TLS-Verschlüsselung mit Zertifikat verstehen sich von selbst!) kommt der entscheidende Punkt: wir machen Baby-Schritte und gucken bei jedem Schritt ob es funktioniert hat. Dazu installieren wir auf unserem PC einen „mqtt-Explorer“ der uns den eigentlichen „Inhalt“ des mqtt-Servers, also die einzelnen Nachrichten und deren Struktur, anzeigen kann. Empfehlenswert ist z.B. der MQTT-Explorer.
Bild MQTT Explorer
Dieser ist nicht mit Funktionen überladen und hat alles was mensch für die ersten Schritte braucht.
Sobald unsere Tests funktionieren und die Test-Nachrichten im Explorer zu sehen sind, wird es kreativ: es ist natürlich zu klären welche „Datenpunkte“ wir überwachen wollen und welche Struktur diese schlussendlich haben sollen. Sinnvoll wäre es für den Anfang den Status diverser System-Dienste zu überwachen. Was nutzt z.B. ein Fail2ban wenn der Dienst beim letzten Logout des Admin versehentlich nicht wieder gestartet wurde?
Der zweite Schritt
heißt also erst einmal die passenden Daten auf dem host zu sammeln und dem mqtt-Server zu übermitteln.
Dazu bastelt mensch sich ein kleines Script das beides in einem Abwasch erledigt. Zum Schluss könnte das vielleicht so aussehen:
Oder so?
Oder so?
Betonung liegt hier allerdings auf AUSSEHEN! Es ist ziemlich unwahrscheinlich, dass das in anderen Umgebungen auf Anhieb läuft. Zusätzlich hat die code-box hier anscheinend ein kleines Problem mit code! ;o)
Wer ellenlange Befehlszeilen des mosquitto_pub vermeiden will, kann außerdem die Standardwerte auch in eine Konfig-Datei im /home-Verzeichnis eintragen.
Wenn das Script dann als Systemd-Dienst eingetragen und über einen Systemd-Timer regelmäßig gestartet wird, ist die halbe Strecke geschafft, und mit einem kühlen Radler in der Hand kann mensch dann stundenlang dem MQTT-Explorer zuschauen wie er bei eintreffenden Nachrichten lustig vor sich hin blinkert. ;o)
Der nächste Schritt
wird nicht weniger anspruchsvoll. Irgendwie brauchen wir etwas, was sich mit unserem mqtt-Broker, so heißt der mqtt-Server eigentlich, verbindet und sich die Nachrichten schicken lässt.
Wie schon erwähnt, besteht ein guter Sicherheitstest für unseren Broker darin, einen Android-Client zu finden der sich mit ihm verbindet. Die meisten verwenden Uralt-Techniken die unser Broker ablehnen sollte.
Ein super Kandidat ist der „MQTT Client“ (in.dc297.mqttclpro) in Version 4.5.1. Der verwendet entweder Systemfunktionen von Android, oder halbwegs aktuelle SSL-Bibliotheken und verbindet sich auch mit unserem Broker. Trotz (hoffentlich[!?]) dessen SSLLabs-A-Rating.
Bild MQTT Client
Außerdem ist er äußerst schlank und bringt eine Schnittstelle zu Tasker mit, was im nächsten Schritt notwendig wird. Als Bonbon obendrauf gibt es mal wieder eine App die ihren Job macht auch ohne irgendwelche dubiosen Rechte zu verlangen. Ein Hoch dieses mal also auf den unbekannten indischen Programmierer!
Wenn sich der MQTT Client erfolgreich mit dem Broker verbunden hat und alle Nachrichten eintrudeln, installieren wir uns die App Tasker. Die kostet unglaubliche 3,50€ ;o) und braucht vermutlich die Play-Dienste um richtig zu funktionieren? Ich kann das leider gerade nicht testen.
Tasker ist eine App die zahllose Automatisierungsfunktionen für Geräte mit Android bereitstellt. Zusätzlich lässt sich Tasker auch gern von anderen Apps zur Mitarbeit bewegen und hat dazu diverse Schnittstellen, unter anderem zu unserem MQTT Client.
Bevor wir Tasker richtig benutzen, sollten allerdings rechts oben im Menü die vielen Android-Rechte eingestellt werden. Tasker ist das genaue Gegenteil vom MQTT Client. Es gibt eigentlich keine Berechtigung mit der Tasker nix anfangen kann. Wer mag, kann bei Anrufen vom Chef auch das Telefon abschalten lassen ;o)
Wenn wir uns also mit Tasker angefreundet haben, folgt
noch ein Schritt
und der ist natürlich die Erkenntnis, dass im Internetzeitalter ein Telefon mit Tasker durchaus zur Waffe werden kann. Und „Waffe ohne Waffenschein“ ist schon mal sehr kritisch zu bewerten. Wer also keine Ahnung hat was Tasker alles weiß und kann, die entsprechenden Berechtigungen natürlich vorausgesetzt, sollte eigentlich die Finger davon lassen! Denn es gibt nix was Tasker nicht weiß. Inklusive dem permanenten Tracking von Ort und Netz und tausend anderen Dingen.
Aber wie schon oben erwähnt: der erfahrene Diplomat kann da einiges machen. Entscheidend ist ja was mit diesen Informationen gemacht wird. Und da sieht es erst einmal nicht so aus als ob Tasker die Server der BigData-Händler dieser Welt füllt. Zumindest sagen logcat und Exodus nichts negatives.
Wenn also das Erstaunen nachlässt, richten wir uns erst einmal den Arbeitsplatz her. Unten im Tasker gibt es den „Home“-Reiter. Da erstellen wir uns gleich mal einen neuen. Das ist gut für die Übersicht und verhindert somit Fehler. Wer es in Deutsch mag, kann auch gleich das Deutsche Sprachpaket installieren.
mqtt-Nachrichten bestehen (für uns) aus 2 Variablen. Einmal das „topic“ und dann die eigentliche „message“. Für jeden Datenpunkt im mqtt-Broker erstellen wir uns im Reiter „Var[iablen]“ also eine Variable für die Nachricht und eine für das zugehörige Topic. „Sprechende“ Namen für die Variablen sind gegen Projektende auch gut für die Übersicht. Die Variablen-Namen sollten Großbuchstaben enthalten, damit diese global gültig sind. Und wer möchte begnügt sich auch erst einmal mit 2 Datenpunkten und den entsprechenden Variablen. Abschließend füllen wir die Topic-Variablen mit den entsprechenden Topics, indem wir nochmal etwas rechts vom Variablen-Namen in das Feld klicken und dort das Topic eintragen. Häkchen! Fertig!
Bild Tasker VAR
Weiterhin brauchen wir noch 2 Variablen für die Kommunikation zwischen Tasker und unseren Tasks. Denn innerhalb von Tasker müssen die externen Daten vom MQTT Client ja irgendwie übergeben werden. Das machen die beiden Variablen.
Wenn alle Variablen angelegt sind (Tasker kommt bei der Variablenansicht gerne mal aus dem Konzept und zeigt nicht alle vorhandenen an. Dann oben beim Häkchen abspeichern und Tasker neu starten) wechseln wir in den Reiter „Szenen“. Dort basteln wir uns eine Fläche mit der gewünschten Anzahl Textfelder. Die Textfelder bekommen als Textinhalt den Wert einer der Message-Variablen. Oder auch die Hintergrundfarbe. Je nachdem welche Nachricht schlussendlich übermittelt wird. Ich mag Farben und meine Nachrichten bestehen aus dem Farbwert. Wenn OK dann gibt es den Farbwert für Grün. Wenn Nicht OK gibt es den Farbwert für Rot. Also kommt die Variable in das Feld für die Hintergrundfarbe.
Bild Tasker Szenenedit
Wenn wir die Testobjekte erstellt haben, wechseln wir in den Reiter Tasks und basteln uns die Aufgabe „Variablen vom MQTT Client übernehmen und auf die einzelnen Variablen der Datenpunkte verteilen“.
Um zu verstehen was da passiert, müssen wir einen Schritt vorwärtsspringen, auch wenn wir den später nochmal gehen müssen: Wir wechseln also in den Reiter „Profile“ und erzeugen ein neues „Profil“ vom Typ „Ereignis“. In der Liste taucht unten der Eintrag „Plugins“ auf. Wenn wir den anwählen, et voilà, da ist er unser MQTT Client. Den aktivieren wir und sehen, dass wir 2 Variablen definieren müssen. Einmal für die Message und einmal für das Topic. Beide Variablen können nur mit Kleinbuchstaben geschrieben werden, d.h., die gelten dann nur innerhalb des zugehörigen Tasks. Um das zu verhindern haben wir uns ja schon 2 Variablen im Reiter VAR vorbereitet.
Wir denken uns also die beiden Variablen-Namen aus, und machen aber erst einmal nichts. Wir schreiben uns halt nur auf wie wir später diese beiden Variablen nennen wollen!!
Zurück im Reiter „Tasks“ beginnen wir mit Schritt 1: die lokalen Variablen vom MQTT Client müssen in unsere globalen Variablen umgewandelt werden. Erst die Eine. Dann die Andere.
Hier gibt es leider einen schweren Fallstrick: „Variable Setzen Variable A zu Variable B“ meint tatsächlich „Variable Setzen: Variable A wird zu Variable B“. In Normaldeutsch also „Variable A nimmt den Wert von Variable B an“.
Anschließend werden einzelne Aufgabenschritte erstellt, bei der unsere Topic-Variable mit dem Wert vom MQTT-Client mit der Topic-Variable im Reiter VAR verglichen wird (da, wo wir schon den entsprechenden Topic händisch eingetragen haben). Das zugehörige IF-Feld gibts unten in dem Formular. Oben steht dann welche Variable A dann zu Variable B wird (wenn IF-Bedingung erfüllt ist). Zwischen den Variablen im IF-Feld muss noch die Bedingung eingestellt werden. In unserem Fall „stimmt überein“.
In der Aktionenansicht (also da wo die Details einer Aufgabe stehen) ist das alles einfacher zu erkennen als direkt im Formular.
Bild Tasker einzelne Aufgabe „Variablen setzen“
Wenn die Aufgaben soweit erstellt sind gehen wir jetzt nochmal in den Reiter „Profile“ und erstellen ein Profil so wie bereits oben beschrieben. Diesmal tragen wir aber die beiden Variablen im MQTT-Client ein und speichern. Zurück im Reiter Profile gibts jetzt rechts neben dem „Ereignis MQTT-Client“ die Möglichkeit eine Aufgabe hinzuzufügen. In der Liste wählen wir die Aufgabe die wir vor Kurzem erstellt haben. Das dürfte dann etwa so aussehen:
Bild Tasker Profilaufgabe
Wenn bis hierhin alles fehlerfrei geklappt hat (ha ha ha) und die erste Nachricht eingetroffen ist, dürfte im Aufgaben-Reiter rechts an den Tasks ein roter oder grüner Balken erscheinen. Das heißt dann „IF-Bedingung erfüllt“ bzw. „nicht erfüllt“.
Wenn Ja müsste im Reiter Szenen jetzt eines der Textfelder, entsprechend unserer gewählten Einstellung, sich verändert haben. Hintergrundfarbe oder Textinhalt oder was auch immer ihr dort konfiguriert haben.
Wenn Nein kann hilfsweise zwischen den Teilaufgaben eine Aktion „Beep“ eingefügt werden. Oder sogar als eigenständige Aufgabe, und dann diese eigenständige Aufgabe im Reiter Profile zusätzlich zur bestehenden Aufgabe ausgewählt werden. Dann gibt es zumindest einen Pieps wenn Tasker eine Nachricht vom MQTT Client übernommen hat. Das wäre ja schon mal etwas ;o)
Ab hier beginnt dann der eigentliche Spaß. Für die hartnäckigen eine langwierige Fehlersuche. Für die pedantischen ein stetiges Weiterbasteln.
Zur Fehlersuche ist der MQTT-Explorer am PC sehr hilfreich. Der sendet auch Phantasiewerte an den Broker, mit denen die Wirkungen im Tasker besser erkennbar werden. Ein Pieps an den richtigen Stellen hilft spürbar!
Wenn alle Datenpunkte und Aufgaben und Textfelder im Tasker eingebaut sind, könnte das vielleicht so aussehen:
Bild Tasker Szene
Jaaa. Design geht anders. Aber praktisch ist es auf jeden Fall.
Finale
Um mit der Szene etwas anfangen zu können erstellen wir jetzt eine neue Aufgabe „Szene anzeigen“ mit unserer Szene als Objekt.
Wenn alles gespeichert ist erstellen wir uns auf dem Home-Screen ein Tasker-Widget „Task“ und wählen dort die Aufgabe „Szene anzeigen“.
Klick! Klick!
Boahh geil!
Bild Tasker Homescreen
Nachwort
Tasker ist unter Fans besser als jede Modelleisenbahn und Harley zusammen. In Verbindung mit einem mqtt-Broker wird aus dem Schweizer Taschenmesser der modernen Informationsgesellschaft ein wahres Messer-Monster. Eines, dass sich von Diplomaten (und Admins ;o) handzahm durch die Welt führen lässt.
Jedes, und ich denke wirklich JEDES weltweit erhältliche MQTT-Dashboard für Android wird da im Vergleich zu einem NICHTS!! ;o)
… und eine versehentlich offene Tresortür könnte der Vergangenheit angehören.
Da sich einzelne Aufgaben einfach deaktivieren lassen, und komplizierte Aufgaben nach einiger Erfahrung zu wenigen Klicks mutieren, werden auch ungewöhnlichste Schaltlogiken gerne realisiert. Gerade auch weil die erzeugten Daten sicher vor fremden Blicken sein können. Wer mag braucht noch nicht einmal selber klicken > es gibt viele Fanseiten die interessante Projekt anbieten die nur noch im Tasker importiert und angepasst werden brauchen.
Aber unser Projekt mag selber auch noch viel Feinarbeit.
So sollte in jedem Fall abschließend mit dem MQTT-Explorer getestet werden ob die Datenpunkte auch wirklich das machen was sie sollen!
Manchmal nervt es z.B. gewaltig, in der Szene das kleine x zum Schließen zu treffen. > Warum also nicht nach 3 Sekunden automatisch schließen lassen?
Der Admin ist zu faul zum Knopfdrücken? > Warum nicht bei jedem Bildschirmentsperren die Szene kurz anzeigen lassen?
Wer war denn heute eigentlich der „Heavy-User des Tages“ mit mehr als 500 Posts/h? > Argh, da fehlt ja noch ein Knopf! ;o)
LG llluuuzzziii
Welche Möglichkeiten es gibt, und die dazu passenden Anleitungen, findet mensch haufenweise im Netz. Aber wie z.B. ein Backup nur dann ein Backup ist, wenn sichergestellt ist, dass die Wiederherstellung funktioniert, ist ein Datentresor nur dann ein Tresor wenn sichergestellt ist, dass die Tür geschlossen ist und das Schloss funktioniert … und der Tresoreigentümer sofort erfährt wenn es nicht so ist.
Wer also seine Daten sicher verschlossen hat sollte sich, wie im realen Leben auch, umgehend einen pflegeleichten aber zuverlässigen Wachhund zulegen. Wenn der dann nicht nur Einbrecher sondern auch offene Türen und kaputte Schlösser erkennt und meldet, und nix kostet … ist eigentlich alles perfekt? ;o)
Selten. Denn kostenlose Wachhunde gibt es zwar sehr viele. Aber entweder sind die nicht sehr pflegeleicht, oder uralt, oder riesengroß … oder fressen jedem Besucher aus der Hand ohne das man das mitbekommt.
Entscheidend ist also nicht nur WIE ein Problem gelöst wird sondern auch WOMIT.
WOMIT bedeutet nicht nur schlank und erprobt und sicher und pflegeleicht … sondern auch zukunftssicher. Und da landet interessierter mensch ziemlich schnell bei Dingen wie „IoT“ und „MQTT“ … der neue heiße Sch*ss für jeden Nerd, und alle die gerne einer wären!? ;o)
Wer dann allerdings im Internet spazieren geht und sich anguckt was manche dort teilweise für vermeintliche „Tresore“ hingestellt haben, bekommt das kalte Grausen. Gerade mit IoT und MQTT!
Dazu zählen insbesondere Anwendungen, die sich als „neuer heißer Sch*ss“ präsentieren, aber Techniken aus dem vorletzten Jahrhundert verwenden.
Bei Tests mit einem sehr gut abgesicherten host gab es letztlich nur einen einzigen mqtt-Client für Android, der mit diesem kommunizieren wollte. Alle anderen waren nicht in der Lage eine Verbindung aufzubauen, weil (heutzutage[!]) unsichere Verbindungen vom server abgelehnt wurden. Glücklicherweise ist das genau einer der Clients die sich sehr gut für die Lösung unseres „Problems“ eignen.
Wer als erprobter Zuhause-Admin oder interessierter Laie einen Tresor aber keinen brauchbaren Wachhund hat, sollte hier also durchaus weiterlesen.
Der Anfang
Als erstes brauchen wir für unseren sicheren server natürlich einen sicheren host. Wer IoT ins Intranet einsperrt (und denkt das muss so sein), oder einen Provider nimmt „weil der sich um Sicherheit kümmert“ ist erst einmal schon, mehr oder weniger auf dem Holzweg. Ein Admin, dem nur in den heimischen Hallen die Probleme des Tages mitgeteilt werden können, hat noch nix von qualifizierter Sorgearbeit gehört!? ;o)
Und wer andererseits Löcher in die heimische Firewall bohrt damit seine Sorgenkinder sich bei ihm jederzeit melden können, riskiert nicht nur Bohrstaub sondern insbesondere neugierige Nachbarn und „Leute, die nur mal schnell irgendein Zeugs zwischenlagern“ wollen?
Letztlich gilt wie schon vor 500 Jahren: sicher lebt nicht der Ritter auf der Burg, der Angst haben muss vor seiner eigenen Torwache, sondern der Diplomatieerfahrene, der Zusammenhänge erkennt und entsprechend vorsorgt. Und bei Erfolg dann auch mal nackt auf dem Felde stehen kann.
In diesem Sinne ist IoT/MQTT nur so sicher wie der host eben Sicherheit bieten kann. Und der sollte unabhängig von IoT oder anderen Diensten sicher sein. Deshalb sei auch hier nochmal dringend ans Herz gelegt, mit Experimenten wie IoT im Internet erst zu starten wenn grundlegende Sicherheit gewährleistet ist. Da gibt es herrliche Helferlein w.z.B. SSLLabs, die die eigenen Ports auditieren, oder wie Mozilla, die bei der Konfiguration von Apache und OpenSSL behilflich sind. Sinnvoll eingesetzt sind auch Dinge wie Fail2ban durchaus hilfreich.
Und dann fällt uns natürlich auf: für einen sicheren server und einen sicheren host brauchen wir natürlich einen server/einen host!? Da sind also alle die „nur“ Webspace oder sogar SaaS nutzen, schon mal Außen vor? Denn Voraussetzung für „selbst in die Hand genommene Sicherheit“ ist natürlich der root-Zugang. Ob dediziert oder virtuell oder sogar als Cloud ist da nicht ganz so wichtig.
Aber da „Draußen“ im überwiegenden Teil unseres Universums gleichzeitig „Drinnen“ bedeutet, kann es natürlich trotzdem den einen oder anderen Weg geben, auch ohne root-Zugang am neuen heißen Sch*ss teilnehmen zu können? Gibt es vielleicht schon mqtt-Plugins für Forensoftware?
Der erste Schritt
Um schnell und zuverlässig und ohne riesigen Aufwand Überwachungsinformationen übertragen zu können bietet sich heute das schon erwähnte mqtt-Protokoll an. Das ist für kleine und kleinste Geräte gedacht und somit intellektuell anspruchslos, halbwegs energiesparsam und entkoppelt alle Beteiligten, so das letztlich jeder nach seiner Fasson leben kann und trotzdem die Kommunikation funktioniert.
Passende mqtt-Server gibt es in einer schier unüberschaubarer Menge. Sehr häufig eingesetzt wird der mosquitto-server, der sich auch auf schmalbrüstigen Hosts kaum in die Knie zwingen lässt. Inklusive kommen dort auch ein Publisher und ein Subscriber für die Kommandozeile mit, die sich prima in Scripte einbauen lassen.
Ist der mqtt-Server installiert und getestet und abgesichert (ein geschlossener Port 1883, aktive Benutzerrechteverwaltung und die TLS-Verschlüsselung mit Zertifikat verstehen sich von selbst!) kommt der entscheidende Punkt: wir machen Baby-Schritte und gucken bei jedem Schritt ob es funktioniert hat. Dazu installieren wir auf unserem PC einen „mqtt-Explorer“ der uns den eigentlichen „Inhalt“ des mqtt-Servers, also die einzelnen Nachrichten und deren Struktur, anzeigen kann. Empfehlenswert ist z.B. der MQTT-Explorer.
Bild MQTT Explorer
Dieser ist nicht mit Funktionen überladen und hat alles was mensch für die ersten Schritte braucht.
Sobald unsere Tests funktionieren und die Test-Nachrichten im Explorer zu sehen sind, wird es kreativ: es ist natürlich zu klären welche „Datenpunkte“ wir überwachen wollen und welche Struktur diese schlussendlich haben sollen. Sinnvoll wäre es für den Anfang den Status diverser System-Dienste zu überwachen. Was nutzt z.B. ein Fail2ban wenn der Dienst beim letzten Logout des Admin versehentlich nicht wieder gestartet wurde?
Der zweite Schritt
heißt also erst einmal die passenden Daten auf dem host zu sammeln und dem mqtt-Server zu übermitteln.
Dazu bastelt mensch sich ein kleines Script das beides in einem Abwasch erledigt. Zum Schluss könnte das vielleicht so aussehen:
Code:
#########################################################
# Systemdienste
dienste=( amavis apache2 clamav-daemon clamav-freshclam ejabberd cron cyrus-imapd dirsrv-admin dirsrv@host1 fail2ban guam kolab-saslauthd kolab-server postfix@- mysql rsync ssh )
#########################################################
#Farben
orange=FFFFA000
gruen=7A00FF00
#########################################################
for i in ${dienste[*]}
do status="$(systemctl is-active $i.service)"
if [ "${status}" = "active" ]
then mosquitto_pub -t server/example.com/watchdog/$i -m $gruen
else mosquitto_pub -t server/example.com/watchdog/$i -m $orange
fi
doneOder so?
Code:
#ssd
festplatte_root="$(df --output=pcent,target|grep -o "..%\? /$"|grep -o [0-9]*)"
mosquitto_pub -t server/example.com/auslastung/ssd/root/belegt -m "$festplatte_root %"Oder so?
Code:
#Laufzeit
uptime_sec=$(cat /proc/uptime | sed 's/[ ].*$//g')
seconds=$uptime_sec
a=$(eval "echo $(date -ud "@$seconds" +'$((%s/3600/24))d %Hh %Mm %Ss')")
mosquitto_pub -t server/example.com/laufzeit -m "$a"Betonung liegt hier allerdings auf AUSSEHEN! Es ist ziemlich unwahrscheinlich, dass das in anderen Umgebungen auf Anhieb läuft. Zusätzlich hat die code-box hier anscheinend ein kleines Problem mit code! ;o)
Wer ellenlange Befehlszeilen des mosquitto_pub vermeiden will, kann außerdem die Standardwerte auch in eine Konfig-Datei im /home-Verzeichnis eintragen.
Wenn das Script dann als Systemd-Dienst eingetragen und über einen Systemd-Timer regelmäßig gestartet wird, ist die halbe Strecke geschafft, und mit einem kühlen Radler in der Hand kann mensch dann stundenlang dem MQTT-Explorer zuschauen wie er bei eintreffenden Nachrichten lustig vor sich hin blinkert. ;o)
Der nächste Schritt
wird nicht weniger anspruchsvoll. Irgendwie brauchen wir etwas, was sich mit unserem mqtt-Broker, so heißt der mqtt-Server eigentlich, verbindet und sich die Nachrichten schicken lässt.
Wie schon erwähnt, besteht ein guter Sicherheitstest für unseren Broker darin, einen Android-Client zu finden der sich mit ihm verbindet. Die meisten verwenden Uralt-Techniken die unser Broker ablehnen sollte.
Ein super Kandidat ist der „MQTT Client“ (in.dc297.mqttclpro) in Version 4.5.1. Der verwendet entweder Systemfunktionen von Android, oder halbwegs aktuelle SSL-Bibliotheken und verbindet sich auch mit unserem Broker. Trotz (hoffentlich[!?]) dessen SSLLabs-A-Rating.
Bild MQTT Client
Außerdem ist er äußerst schlank und bringt eine Schnittstelle zu Tasker mit, was im nächsten Schritt notwendig wird. Als Bonbon obendrauf gibt es mal wieder eine App die ihren Job macht auch ohne irgendwelche dubiosen Rechte zu verlangen. Ein Hoch dieses mal also auf den unbekannten indischen Programmierer!
Wenn sich der MQTT Client erfolgreich mit dem Broker verbunden hat und alle Nachrichten eintrudeln, installieren wir uns die App Tasker. Die kostet unglaubliche 3,50€ ;o) und braucht vermutlich die Play-Dienste um richtig zu funktionieren? Ich kann das leider gerade nicht testen.
Tasker ist eine App die zahllose Automatisierungsfunktionen für Geräte mit Android bereitstellt. Zusätzlich lässt sich Tasker auch gern von anderen Apps zur Mitarbeit bewegen und hat dazu diverse Schnittstellen, unter anderem zu unserem MQTT Client.
Bevor wir Tasker richtig benutzen, sollten allerdings rechts oben im Menü die vielen Android-Rechte eingestellt werden. Tasker ist das genaue Gegenteil vom MQTT Client. Es gibt eigentlich keine Berechtigung mit der Tasker nix anfangen kann. Wer mag, kann bei Anrufen vom Chef auch das Telefon abschalten lassen ;o)
Wenn wir uns also mit Tasker angefreundet haben, folgt
noch ein Schritt
und der ist natürlich die Erkenntnis, dass im Internetzeitalter ein Telefon mit Tasker durchaus zur Waffe werden kann. Und „Waffe ohne Waffenschein“ ist schon mal sehr kritisch zu bewerten. Wer also keine Ahnung hat was Tasker alles weiß und kann, die entsprechenden Berechtigungen natürlich vorausgesetzt, sollte eigentlich die Finger davon lassen! Denn es gibt nix was Tasker nicht weiß. Inklusive dem permanenten Tracking von Ort und Netz und tausend anderen Dingen.
Aber wie schon oben erwähnt: der erfahrene Diplomat kann da einiges machen. Entscheidend ist ja was mit diesen Informationen gemacht wird. Und da sieht es erst einmal nicht so aus als ob Tasker die Server der BigData-Händler dieser Welt füllt. Zumindest sagen logcat und Exodus nichts negatives.
Wenn also das Erstaunen nachlässt, richten wir uns erst einmal den Arbeitsplatz her. Unten im Tasker gibt es den „Home“-Reiter. Da erstellen wir uns gleich mal einen neuen. Das ist gut für die Übersicht und verhindert somit Fehler. Wer es in Deutsch mag, kann auch gleich das Deutsche Sprachpaket installieren.
mqtt-Nachrichten bestehen (für uns) aus 2 Variablen. Einmal das „topic“ und dann die eigentliche „message“. Für jeden Datenpunkt im mqtt-Broker erstellen wir uns im Reiter „Var[iablen]“ also eine Variable für die Nachricht und eine für das zugehörige Topic. „Sprechende“ Namen für die Variablen sind gegen Projektende auch gut für die Übersicht. Die Variablen-Namen sollten Großbuchstaben enthalten, damit diese global gültig sind. Und wer möchte begnügt sich auch erst einmal mit 2 Datenpunkten und den entsprechenden Variablen. Abschließend füllen wir die Topic-Variablen mit den entsprechenden Topics, indem wir nochmal etwas rechts vom Variablen-Namen in das Feld klicken und dort das Topic eintragen. Häkchen! Fertig!
Bild Tasker VAR
Weiterhin brauchen wir noch 2 Variablen für die Kommunikation zwischen Tasker und unseren Tasks. Denn innerhalb von Tasker müssen die externen Daten vom MQTT Client ja irgendwie übergeben werden. Das machen die beiden Variablen.
Wenn alle Variablen angelegt sind (Tasker kommt bei der Variablenansicht gerne mal aus dem Konzept und zeigt nicht alle vorhandenen an. Dann oben beim Häkchen abspeichern und Tasker neu starten) wechseln wir in den Reiter „Szenen“. Dort basteln wir uns eine Fläche mit der gewünschten Anzahl Textfelder. Die Textfelder bekommen als Textinhalt den Wert einer der Message-Variablen. Oder auch die Hintergrundfarbe. Je nachdem welche Nachricht schlussendlich übermittelt wird. Ich mag Farben und meine Nachrichten bestehen aus dem Farbwert. Wenn OK dann gibt es den Farbwert für Grün. Wenn Nicht OK gibt es den Farbwert für Rot. Also kommt die Variable in das Feld für die Hintergrundfarbe.
Bild Tasker Szenenedit
Wenn wir die Testobjekte erstellt haben, wechseln wir in den Reiter Tasks und basteln uns die Aufgabe „Variablen vom MQTT Client übernehmen und auf die einzelnen Variablen der Datenpunkte verteilen“.
Um zu verstehen was da passiert, müssen wir einen Schritt vorwärtsspringen, auch wenn wir den später nochmal gehen müssen: Wir wechseln also in den Reiter „Profile“ und erzeugen ein neues „Profil“ vom Typ „Ereignis“. In der Liste taucht unten der Eintrag „Plugins“ auf. Wenn wir den anwählen, et voilà, da ist er unser MQTT Client. Den aktivieren wir und sehen, dass wir 2 Variablen definieren müssen. Einmal für die Message und einmal für das Topic. Beide Variablen können nur mit Kleinbuchstaben geschrieben werden, d.h., die gelten dann nur innerhalb des zugehörigen Tasks. Um das zu verhindern haben wir uns ja schon 2 Variablen im Reiter VAR vorbereitet.
Wir denken uns also die beiden Variablen-Namen aus, und machen aber erst einmal nichts. Wir schreiben uns halt nur auf wie wir später diese beiden Variablen nennen wollen!!
Zurück im Reiter „Tasks“ beginnen wir mit Schritt 1: die lokalen Variablen vom MQTT Client müssen in unsere globalen Variablen umgewandelt werden. Erst die Eine. Dann die Andere.
Hier gibt es leider einen schweren Fallstrick: „Variable Setzen Variable A zu Variable B“ meint tatsächlich „Variable Setzen: Variable A wird zu Variable B“. In Normaldeutsch also „Variable A nimmt den Wert von Variable B an“.
Anschließend werden einzelne Aufgabenschritte erstellt, bei der unsere Topic-Variable mit dem Wert vom MQTT-Client mit der Topic-Variable im Reiter VAR verglichen wird (da, wo wir schon den entsprechenden Topic händisch eingetragen haben). Das zugehörige IF-Feld gibts unten in dem Formular. Oben steht dann welche Variable A dann zu Variable B wird (wenn IF-Bedingung erfüllt ist). Zwischen den Variablen im IF-Feld muss noch die Bedingung eingestellt werden. In unserem Fall „stimmt überein“.
In der Aktionenansicht (also da wo die Details einer Aufgabe stehen) ist das alles einfacher zu erkennen als direkt im Formular.
Bild Tasker einzelne Aufgabe „Variablen setzen“
Wenn die Aufgaben soweit erstellt sind gehen wir jetzt nochmal in den Reiter „Profile“ und erstellen ein Profil so wie bereits oben beschrieben. Diesmal tragen wir aber die beiden Variablen im MQTT-Client ein und speichern. Zurück im Reiter Profile gibts jetzt rechts neben dem „Ereignis MQTT-Client“ die Möglichkeit eine Aufgabe hinzuzufügen. In der Liste wählen wir die Aufgabe die wir vor Kurzem erstellt haben. Das dürfte dann etwa so aussehen:
Bild Tasker Profilaufgabe
Wenn bis hierhin alles fehlerfrei geklappt hat (ha ha ha) und die erste Nachricht eingetroffen ist, dürfte im Aufgaben-Reiter rechts an den Tasks ein roter oder grüner Balken erscheinen. Das heißt dann „IF-Bedingung erfüllt“ bzw. „nicht erfüllt“.
Wenn Ja müsste im Reiter Szenen jetzt eines der Textfelder, entsprechend unserer gewählten Einstellung, sich verändert haben. Hintergrundfarbe oder Textinhalt oder was auch immer ihr dort konfiguriert haben.
Wenn Nein kann hilfsweise zwischen den Teilaufgaben eine Aktion „Beep“ eingefügt werden. Oder sogar als eigenständige Aufgabe, und dann diese eigenständige Aufgabe im Reiter Profile zusätzlich zur bestehenden Aufgabe ausgewählt werden. Dann gibt es zumindest einen Pieps wenn Tasker eine Nachricht vom MQTT Client übernommen hat. Das wäre ja schon mal etwas ;o)
Ab hier beginnt dann der eigentliche Spaß. Für die hartnäckigen eine langwierige Fehlersuche. Für die pedantischen ein stetiges Weiterbasteln.
Zur Fehlersuche ist der MQTT-Explorer am PC sehr hilfreich. Der sendet auch Phantasiewerte an den Broker, mit denen die Wirkungen im Tasker besser erkennbar werden. Ein Pieps an den richtigen Stellen hilft spürbar!
Wenn alle Datenpunkte und Aufgaben und Textfelder im Tasker eingebaut sind, könnte das vielleicht so aussehen:
Bild Tasker Szene
Jaaa. Design geht anders. Aber praktisch ist es auf jeden Fall.
Finale
Um mit der Szene etwas anfangen zu können erstellen wir jetzt eine neue Aufgabe „Szene anzeigen“ mit unserer Szene als Objekt.
Wenn alles gespeichert ist erstellen wir uns auf dem Home-Screen ein Tasker-Widget „Task“ und wählen dort die Aufgabe „Szene anzeigen“.
Klick! Klick!
Boahh geil!
Bild Tasker Homescreen
Nachwort
Tasker ist unter Fans besser als jede Modelleisenbahn und Harley zusammen. In Verbindung mit einem mqtt-Broker wird aus dem Schweizer Taschenmesser der modernen Informationsgesellschaft ein wahres Messer-Monster. Eines, dass sich von Diplomaten (und Admins ;o) handzahm durch die Welt führen lässt.
Jedes, und ich denke wirklich JEDES weltweit erhältliche MQTT-Dashboard für Android wird da im Vergleich zu einem NICHTS!! ;o)
… und eine versehentlich offene Tresortür könnte der Vergangenheit angehören.
Da sich einzelne Aufgaben einfach deaktivieren lassen, und komplizierte Aufgaben nach einiger Erfahrung zu wenigen Klicks mutieren, werden auch ungewöhnlichste Schaltlogiken gerne realisiert. Gerade auch weil die erzeugten Daten sicher vor fremden Blicken sein können. Wer mag braucht noch nicht einmal selber klicken > es gibt viele Fanseiten die interessante Projekt anbieten die nur noch im Tasker importiert und angepasst werden brauchen.
Aber unser Projekt mag selber auch noch viel Feinarbeit.
So sollte in jedem Fall abschließend mit dem MQTT-Explorer getestet werden ob die Datenpunkte auch wirklich das machen was sie sollen!
Manchmal nervt es z.B. gewaltig, in der Szene das kleine x zum Schließen zu treffen. > Warum also nicht nach 3 Sekunden automatisch schließen lassen?
Der Admin ist zu faul zum Knopfdrücken? > Warum nicht bei jedem Bildschirmentsperren die Szene kurz anzeigen lassen?
Wer war denn heute eigentlich der „Heavy-User des Tages“ mit mehr als 500 Posts/h? > Argh, da fehlt ja noch ein Knopf! ;o)
LG llluuuzzziii