Eine weitere logstash Schulung ist abgeschlossen

Schulungen
Letzte Woche hat wieder eine logstash Schulung stattgefunden. Es freut mich sehr, dass die Schulung so grossen Anklang findet und neben unseren regulären Schulungsterminen auch Inhouse Termine bei Kunden im geschlossenen Rahmen gebucht werden. Das bedeutet bei Tools wie logstash und dem Rest des ELK Stacks (Elasticsearch – logstash – Kibana) aber auch ein ständiges Überarbeiten der Unterlagen. Die Entwicklung bei den in den Schulungen durchgenommenen Komponenten geht so rasch voran, dass bisher keine zwei Schulungen die selben Unterlagen hatten.
Wurde die erste Schulung noch mit logstash 1.3.3 durchgeführt, waren die letzten Unterlagen schon bei 1.4.0 (1.4.1 war dann doch zu kurzfristig released worden, um noch mit aufgenommen zu werden.) Genauso wurde Elasticsearch ab Version 1.0 behandelt. In der Zwischenzeit sind die Unterlagen schon wieder auf einem neueren Stand und dabei hat die letzte Schulung erst vor einer Woche stattgefunden! Elasticsearch wird in der nächsten Schulung mindestens ab Version 1.2 vertreten sein.
Dass dabei nicht einfach nur Downloadlinks ausgetauscht werden können erkennt man, sobald man die Changelogs der einzelnen Komponenten durchliest. So hat sich nicht nur die Installation von logstash mit Version 1.4 ziemlich geändert, sondern auch die Pakete sind brauchbarer geworden und werden nun für die Schulung verwendet. Elasticsearch braucht nun auch kein Plugin wie knapsack mehr, um es backupen zu können, sondern kann das ganz alleine. Dabei enthalten die Unterlagen aber auch noch die alten Vorgehensweisen für den Fall, dass jemand bereits den ELK Stack in einer alten Version einsetzt. Bei dieser rasanten Entwicklung werden alte Versionen aber nicht allzu lange weitergeführt werden, sonst bestehen die Unterlagen bald nur mehr aus Sonderfällen für ältere Software. logstash_01
Erweitert wurden die Unterlagen unter anderem um eine Anbindung an Graphite und ein Konzept, mit dem besonders zeitintensive Filter wie DNS Abfragen ausgelagert werden können.
Aber nicht nur Updates und neue Ideen fliessen in die Unterlagen ein. Auch das Feedback der bisherigen Teilnehmer hat einen Einfluss auf die weitere Entwicklung. So waren diesmal mehr Beispieldaten vorhanden, falls die Teilnehmer allzu rasch mit dem Stoff weiterkommen. Dass die nicht genutzt wurden, lag aber nicht daran, dass die Teilnehmer langsam gewesen wären, sondern weil sie selbst ganz konkrete Vorstellung für Beispiele hatten, die wir besprechen konnten. Ebenfalls dem Feedback ist es zu verdanken, dass es demnächst mehr zum Thema Monitoring des ELK Stacks geben wird. Sowohl in den Unterlagen, als auch hier im Blog.
Die neuen Unterlagen benötigen sogar deutlich weniger Toner beim Druck, da Screenshots durch Varianten mit einem hellen Kibana Farbschema ersetzt wurden.
Alle Änderungen hier aufzuzählen würde wohl wenig Sinn machen, aber hoffentlich konnte ich vermitteln, dass es voran geht mit den logstash Schulungen und dass wir versuchen, den Teilnehmern wirklich aktuelle und damit brauchbare Information zu bieten.
Wer also noch keine Schulung gebucht hat, sollte das jetzt bald machen und wer schon eine hatte, kann gerne nochmal teilnehmen und sich die Unterschiede ansehen. 😉

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...

GnuPG / GPG Best Practices

Dieser Artikel richtet sich an User, die bereits etwas Erfahrung mit GnuPG / GPG / OpenPGP haben. GnuPG liefert bereits sehr brauchbare Standardeinstellungen mit und es kann ohne Probleme ohne grossen Zusatzaufwand verwendet werden. Wer aber etwas tiefer eintauchen, höhere Sicherheit und mehr Komfort möchte, findet im Folgenden einige Vorschläge.
Die Konfiguration
Normalerweise konfiguriert man GnuPG durch ein Konfigfile, meist ~/.gnupg/gpg.conf. Einige graphische Frontends sollten einige dieser Optionen auch anbieten und sie gegebenenfalls in eine Konfigurationsdatei schreiben.
Bei mir sieht das so aus:

default-key 91B8ECDC6265BAE6
default-recipient-self
keyserver hkp://keys.gnupg.net
keyserver-options auto-key-retrieve
personal-digest-preferences SHA512 SHA384 SHA256 SHA224
personal-cipher-preferences AES256 AES192 AES
personal-compress-preferences SHA512 SHA384 SHA256 SHA224
cert-digest-algo SHA512
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
use-agent
verify-options show-uid-validity

Nicht alle Optionen sind für die Verwendung des Schlüssels für sichere E-Mail wichtig, sondern werden mehr beim Verschlüsseln und Signieren von Dateien auf der Kommandozeile verwendet. Die Optionen können auch beim Aufruf von gpg auf der Kommandozeile angegeben werde. Eine Liste findet sich auf der GnuPG Homepage.
Der default-key gibt einfach an, welcher Schlüssel als eigener Schlüssel für Signaturen oder Verschlüsselung an sich selbst verwendet wird. Dabei wird eine längere Fassung der ID verwendet, da es bei der 8 stelligen Kurzfassung, die man oft sieht, zu leicht zu Kollisionen kommen kann. Wer meinen Schlüssel betrachtet, wird sehen, dass ich auch noch nicht alle dieser Ratschläge mit diesem Key umgesetzt habe. Ein neuer Schlüssel ist generiert, hat aber noch zu wenig Signaturen, um ihn sinnvoll zu verwenden. Es ist also nur mehr eine Frage der Zeit, bis ich mich an meine eigenen Empfehlungen halte. 🙂
Die Option default-recipient-self gibt an, dass man beim Verschlüsseln auf der Kommandozeile keinen Empfänger angeben muss, sondern immer mit dem eigenen Key verschlüsselt wird, wenn keine ID angegeben wird.
Mit keyserver wird der Standardkeyserver angegeben, der genutzt wird, wenn kein anderer Schlüsselserver auf der Kommandozeile genannt wird. Dabei wird immer wieder davor gewarnt, pgp.mit.edu als Keyserver zu verwenden, da dieser berüchtigt dafür ist, Daten nicht sauber mit anderen Servern zu synchronisieren. Welcher andere Keyserver genannt wird, ist meist nebensächlich, da sich eigentlich alle Keyserver miteinander abgleichen sollen.
Durch keyserver-options auto-key-retrieve werden Schlüssel, die im Keyring fehlen, aber zum Verifizieren von Signaturen benötigt werden, automatisch geholt.
Die personal-digest-preferences, personal-cipher-preferences und personal-compress-preferences Listen geben an, welche dieser Algorithmen man bevorzugt, in absteigender Reihenfolge. Beim Versand einer Nachricht wird damit jeweils von links an nach dem ersten Algorithmus gesucht, den alle Empfänger unterstützen. So ist sichergestellt, dass möglichst starke Standards verwendet werden, aber auch an ältere oder suboptimal konfigurierte Clients versandt werden kann. Gibt man z.B. keinen Digest (Hashing) Algorithmus aus der SHA-2 Familie an, nutzt GnuPG Standardmässig SHA-1 für Hashing, was nicht mehr empfohlen werden kann. Es sollte unbedingt ein Algorithmus aus der SHA-2 Familie vor SHA-1 und MD5 in der Liste stehen. Welche Algorithmen in der eigenen Installation zur Verfügung stehen, sieht man übrigens bei einem Aufruf von gpg --version. Bei diesen Optionen eine Liste anzugeben, verhindert den Versand nicht, da immer ein Algorithmus gewählt wird, den alle Empfänger verstehen. Das bedeutet aber auch, dass unter Umständen dennoch unsichere Algorithmen verwendet werden.
Die Option cert-digest-algo ist etwas tückisch. Sie gibt an, welcher Hash Algorithmus beim Signieren von fremden Schlüsseln verwendet wird. Wird der nicht von anderen Usern unterstützt, können Signaturen nicht überprüft werden. Gilt das auch für die Selbstsignatur eines Schlüssels, kann er gar nicht vom Kommunikationspartner verwendet werden. Standard ist eigentlich MD5 für PGP2 Schlüssel und SHA-1 für alle anderen Schlüssel. Da diese aber nicht mehr verwendet werden sollten, steht man vor der Wahl: Unsicherer Algorithmus oder unter Umständen Inkompatibilität zu anderen Usern. Ich habe mich bei neuen Schlüsseln für die mögliche Inkompatibilität entschieden. Vielleicht kann ich damit ja auch den einen oder anderen User zum Upgrade auf eine sichere Version bewegen. Da Signaturen normalerweise nur einmal erstellt werden, sollte man diese Option unbedingt setzen, bevor man einen neuen Schlüssel erstellt. Aus den genannten Gründen führen auch manche Seiten diese Option als “esoteric option” auf. 🙂
Mit default-preference-list gibt man an, welche Algorithmen man selbst unterstützen möchte. Diese Liste wird beim Erstellen eines neuen Schlüssels verwendet, sie sollte also unbedingt gesetzt werden, bevor man einen Schlüssel erstellt. Diese Liste wird auch im Schlüssel verankert und daraus und aus den oben genannten personal-...-preferences wird dann die beste bevorzugte Version ausgesucht, die von allen Beteiligten unterstützt wird. Diese Einstellung kann auch nachträglich am Schlüssel geändert werden. Allerdings muss dann der Absender wieder den aktuellen Schlüssel haben, um die aktuelle Liste zu verwenden. Also auch gleich lieber vor Erstellung eines neuen Schlüssels richtig setzen.
use-agent gibt lediglich an, dass der GnuPG Agent verwendet wird, sofern verfügbar. Damit wird eine eingegebene Passphrase für einige Zeit gespeichert und man muss sie nicht gleich erneut eingeben.
Zu guter letzt sorgt verify-options show-uid-validity dafür, dass beim Anzeigen von UIDs auch gleich deren Gültigkeit angezeigt wird.
Beim Erstellen neuer Schlüssel zu beachten
Wie erwähnt, macht es Sinn, die Optionen in der Konfigurationsdatei zu setzen, bevor man einen Schlüssel erstellt.
Mit gpg --gen-key wird die Erstellung eines neuen Schlüssels gestartet. Ausnahmsweise sei es auch erlaubt, eine GUI dafür zu verwenden. 😉 Dieser Artikel richtet sich an Fortgeschrittene, weshalb auf die Erstellung an sich nicht weiter eingegangen wird.
Als Schlüsselpaar wird bei aktuelleren GnuPG Installationen bereits RSA/RSA vorgeschlagen, was auch übernommen werden sollte.
Dann kommt das leidige Thema der Schlüssellänge. Hier gilt fast noch mehr, als bei den Algorithmen, dass davon die Kompatibilität zu Kommunikationspartnern abhängt. Die meisten sollten inzwischen 4096bit unterstützen. Weniger sollte man alleine schon deshalb nicht mehr wählen, weil man den Schlüssel ja einige Zeit behalten möchte und 4096bit noch länger aktuell bleiben wird, als kürzere Schlüssel. Längere Schlüssel werden noch immer von zu wenig Clients unterstützt. Wobei man bedenken sollte, dass viele Clients zwar keine Erstellung von Schlüsseln über einer bestimmten Länge anbieten, aber sehr wohl mit solchen umgehen können. Es gibt noch weitere Gründe, warum es nicht unbedingt sinnvoll ist, längere Schlüssel als 4096bit zu erstellen, aber dazu vielleicht später mehr.
Es gibt einige Artikel, die darauf eingehen, ob es Sinn macht, ein Kommentar zum Schlüssel hinzuzufügen. Wobei die meisten entweder sehr dafür oder sehr dagegen sind. Ich selbst füge nur mehr Kommentare hinzu, wenn es für mich Sinn macht. Ein Beispiel wäre “package signing key” für Schlüssel, über die ich eigentlich nicht kommunizieren möchte. Kommentare, die nur Informationen enthalten, die man auch aus der zu der uid gehörigen E-Mail Adresse entnehmen kann, kann man getrost weglassen.
Wichtig ist, ein Ablaufdatum festzulegen. Einige Seiten empfehlen, es nicht weiter als 5 Jahre in die Zukunft zu setzen. Es kann jederzeit, auch nach Ablauf des Schlüssels, verändert werden. Nach einer Änderung sollte der Schlüssel wieder auf einen Keyserver hochgeladen werden. Auch wenn man noch so darauf achtet, kann es passieren, dass man den privaten Teil des Schlüssels verliert oder die Passphrase vergisst. Dann sollte der Schlüssel nicht ewig über die Keyserver geistern, sondern irgendwann entfernt werden. Dabei geht es weniger darum, dass Ressourcen gespart werden, sondern mehr darum, dass ein Kommunikationspartner auch wirklich nur Schlüssel von den Keyservern holt, die auch noch zum Entschlüsseln genutzt werden können. Ähnliches gilt, wenn der Besitzer des Schlüssels ihn aus anderen Gründen nicht mehr nutzen kann (z.B. weil er verstorben ist)
Nach dem Erstellen des Schlüssels
Als erstes sollte ein Revocation Certificate erstellt werden. gpg --output revoke.asc --gen-revoke [keyid] Dieses sollte an einem sicheren Platz (USB Stick in einem Tresor, Truecrypt Container, oder vergleichbares) abgespeichert und evtl. sogar ausgedruckt (dazu beim Erstellen die Option --armor verwenden, um das Zertifikat als ASCII zu erhalten) werden, um sie im schlimmsten Fall abzutippen. Mit diesem Zertifikat kann der Schlüssel ungültig gemacht werden, ohne, dass man den privaten Teil oder die Passphrase braucht. Das ist einerseits gut, wenn man einen oder beide dieser Teile verloren hat, aber andererseits sehr gefährlich, weil jeder damit den Schlüssel ungültig machen kann. Um es zu verwenden, importiert man es einfach in seinen Schlüsselbund und lädt den Schlüssel auf einen Keyserver hoch. Ab da scheint er bei jedem als ungültig auf, der die aktuelle Version des Schlüssels hat.
Dann können weitere IDs zu dem Schlüssel hinzugefügt werden. Eine für jede E-Mail Adresse, mit der man den Schlüssel verwenden will. Einige Anleitungen empfehlen auch, eine ID ohne E-Mail Adresse hinzuzufügen, da sich der Name seltener ändert als E-Mail Adressen. Ich bin ein Freund davon, sich zumindest eine Adresse mit einer eigenen Domain zuzulegen, die sich möglichst nie ändert, was diesen Grund wieder relativiert. Ausserdem signieren manche automatisierte Tools nur “aktive” IDs, also solche, von deren E-Mail Adressen man auch Nachrichten empfangen kann, was hier ebenfalls nicht funktionieren würde. Es spricht aber auch nicht wirklich etwas gegen das Erstellen einer solchen ID.
Eine Photo ID finde ich persönlich sinnvoll, vor allem wenn man Schlüssel nur bei persönlichem Kontakt signiert. Legt man sich selbst eine Signatur Policy zurecht, die auch Signaturen ohne persönliches Treffen erlauben, kann es sinnvoll sein, auf die Signatur einer Photo ID zu verzichten. Man kann ja auch einzelne IDs signieren.
Mit gpg --send-key [keyid] schickt man den Schlüssel dann an den konfigurierten Keyserver. An sich reicht es, ihn an einen Server zu senden, da sich die Keyserver untereinander synchronisieren. In der Praxis funktioniert das nicht immer reibungslos, aber im Allgemeinen findet jeder Schlüssel früher oder später den Weg zu den einzelnen Servern.
Regelmässige Wartung
Da, anders als bei S/MIME, aktualisierte Schlüssel nicht beim Versand von E-Mails übertragen werden, sondern immer wieder vom Keyserver geladen werden müssen, ist es sehr wichtig, die Schlüssel regelmässig von einem Keyserver zu aktualisieren. Dazu habe ich folgenden Eintrag in meiner crontab: 40 5 * * 4 /usr/bin/gpg --refresh-keys --keyserver-options no-honor-keyserver-url ; /usr/bin/gpg --refresh-keys --keyserver-options honor-keyserver-url . Das funktioniert, weil ich das Gerät regelmässig für Wartungsaufgaben über Nacht laufen lasse. Wer das anders hält, muss eben die Zeit des cronjobs anpassen. Dabei führe ich --refresh-keys zwei mal aus. Einmal hole ich die Schlüssel von dem Keyserver, den ich mir als Standard konfiguriert habe und einmal von dem Keyserver, den die Schlüsselbesitzer evtl. in ihren Schlüsseln hinterlegt haben. Damit respektiere ich einerseits, falls jemand seinen Schlüssel an einem bestimmten Server pflegt, der sich unter Umständen gar nicht mit anderen Schlüsselservern synchronisiert und bin andererseits dafür gewappnet, dass jemand evtl. einen Server angegeben hat, der gar nicht mehr existiert. Wer keinen hkps fähigen Keyserver verwendet, überträgt damit regelmässig eine Liste der Schlüssel im eigenen Keyring und damit wahrscheinlich eine Liste der regelmässigen Kommunikationspartner. Es gibt Tools, die helfen, das zu Verschleiern, ohne auf hkps umsteigen zu müssen, da aber keine weitere Information enthalten ist, hebe ich Anleitungen dafür für etwaige spätere Artikel auf.
Mit dem Befehl gpg --update-trustdb kann man die Trust-DB ausfüllen. Damit gibt man für alle Schlüssel, für die man das noch nicht getan hat, an, wie sehr man dem Besitzer zutraut, Schlüssel anderer Personen nur nach ordentlicher Überprüfung der Identität zu vertrauen. Diese Information hat durchaus mit der persönlichen Meinung über die Besitzer zu tun und sollte deshalb sehr vertraulich behandelt werden. Sie wird auch nicht mit einem Schlüssel exportiert. Zu beachten ist, dass dies nichts damit zu tun hat, wie sehr man dem Besitzer eines Schlüssels glaubt, tatsächlich der zu sein, der er zu sein vorgibt. Diesen Befehl sollte man regelmässig ausführen, da diese Einstufung bei jedem neu importierten Schlüssel nötig ist. Das muss interaktiv passieren, deshalb macht es keinen Sinn, einen Cronjob dafür zu planen.
Zum Backup der geheimen Schlüssel sollte man ab und zu gpg --export-secret-keys --armor ausführen und den Output an einem sicheren Ort speichern. Zwar ist der Schlüssel mit der Passphrase geschützt, aber nur darauf sollte man sich auf keinen Fall verlassen. Die öffentlichen Schlüssel kann man zwar von Schlüsselservern neu holen, aber wenn man schon mal dabei ist: gpg --export --armor.
Es ist auch sinnvoll, immer wieder zu kontrollieren, ob das Ablaufdatum des Schlüssels nicht kurz bevor steht. Da es einige Zeit braucht, bis alle Kommunikationspartner einen aktualisierten Schlüssel holen, sollte man früh genug damit beginnen, das Ablaufdatum wieder nach hinten zu verschieben und den öffentlichen Schlüssel über die Keyserver zu verteilen.
Als stolzer Schlüsselbesitzer sollte man regelmässig versandte Mails signieren. Das ist wahrscheinlich der effektivste Weg, herauszufinden, ob man nicht unter seinen regelmässigen Kommunikationspartnern auch GnuPG Anwender hat. Ausserdem wird so oft die Rückfrage kommen, was denn “diese komischen Zeichen” sein sollen. Ein sehr praktischer Weg, um ein Gespräch über sichere E-Mailkommunikation zu beginnen. 🙂
Was man sonst noch tun kann
Natürlich sollte man über diesen Vorschlägen nicht vergessen, den Schlüssel einfach auch mal zu verwenden. Zum Signieren und Verschlüsseln von E-Mails, Signieren von Softwarepaketen, Verschlüsseln von Dateien, die man sicher aufbewahren will und einiges mehr.
Die wichtigste Regel im Umgang mit E-Mail Sicherheit ist meiner Meinung die gleiche, die ich für Wiederbelebung in der Ersten Hilfe gelernt habe: Hauptsache, man tut’s. Auch wenn man sich nicht ans Handbuch hält und vielleicht nicht alles perfekt ausführt, ist es immer noch viel, viel besser, als nichts zu tun. Bei beidem gilt jedoch auch, dass man immer nur Chancen verschieben kann. 100% Erfolgschance gibt es bei beidem leider nicht, auch wenn man noch so gut vorbereitet ist. Je besser man sich vorbereitet, umso höher sind aber die Chancen des Erfolges. Sicher ist nur eines: Macht man nichts, sieht’s düster aus.
Für alle, die sich dennoch gerne vorbereiten wollen, soll dieser Artikel einen Anhaltspunkt für den E-Mail Teil des Vergleichs geben, für den Rest gibt’s hier, hier und bei vielen anderen Stellen, die ich leider hier aus Platzgründen nicht mehr nennen kann, Angebote.
Für die Nerds und Geeks unter den Lesern findet sich viel Spass mit Graphen und Statistiken zu Schlüsseln auf http://pgp.cs.uu.nl/
Natürlich gibt es noch viel mehr, was man mit GnuPG und GPG Schlüsseln machen kann, was sich im täglichen Leben als praktisch und/oder sicher erweist, aber als Start sollte dieser Artikel einige Anhaltspunkte geben. Sollte Bedarf bestehen, können gerne Einführungsanleitungen folgen. Eine wunderbare Anwendung des Kommentarfeldes, solchen Bedarf anzumelden. 🙂
Noch eine Anmerkung: Sicherheitstechnologien sind einem ständigen Wandel unterworfen. Es lohnt sich also immer, mal kurz nach dem aktuellen Stand der Technik zu suchen, um zu vergleichen, ob die Informationen nicht schon wieder überholt sind. Bei Kommunikationstechnologien ist das doppelt wichtig, da sich Sender und Empfänger auf einen Satz an Technologien einigen müssen. Dafür wird  oft eine gewichtete Liste konfiguriert, welche Technologien unterstützt werden und welche bevorzugt werden. Das sollte nicht zu restriktiv gehalten werden, sonst kann es schon zu Problemen beim Versand von E-Mails von sehr konservativen Betriebssystemen an Bleeding-Edge OS und umgekehrt kommen. Beispiele solcher Listen finden sich oben in dem Beispiel der Konfigurationsdatei.
Für weitere Vorschläge anderer Best Practices bietet sich ebenfalls die Kommentarfunktion an.
Ein paar weiterführende Links zum Thema:

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...

Wie krieg ich mein Windows in dein logstash?

Auch wenn’s unüblich für mich ist, so muss ich fast auch etwas dazu schreiben, wie man Windows Logs in eine logstash Installation bekommt.
Dafür gibt es, wie so oft, mehrere Möglichkeiten, die auch von den Details der Frage abhängen. Vor allem gilt es erst zu spezifizieren, welche Logs man denn überhaupt haben will. Windows Eventlog? Logs einer Applikation, die ein Eventlog anlegt? Logs einer Applikation, die eigene Logfiles auf das Filesystem schreibt?
Die universelle Lösung bleibt hier logstash selbst. Als Java (genauer JRuby) Anwendung sollte logstash auf jeder Plattform laufen, die Java ausführen kann. Wer mal mehr Java Anwendungen auf diversen verschiedenen Systemen logstash_01ausführen musste, darf über das “sollte” schmunzeln, alle anderen mögen es mir verzeihen. Tatsächlich ist logstash aber ziemlich unempfindlich, welche Java Version zum Einsatz kommt. Einzig im Zusammenhang mit Elasticsearch sollte darauf geachtet werden, auf allen beteiligten Hosts wirklich die gleiche Java Version einzusetzen.
Für Windows bringt logstash auch gleich den eventlog Input mit. Details zur Konfiguration gibt es wie immer in der logstash Dokumentation.
Die Konfiguration ist aber auch hier so einfach, dass es schade wäre, kein Beispiel dafür zu nennen.

input {
  eventlog {
    type  => 'proprietarylogs'
    logfile  => 'System'
  }
}

In der Option logfile gibt man ein Array von Namen von Eventlogs an, die man ausgewertet haben möchte. Für Logs, die nicht im Eventlog liegen, wie Logfiles, die von Applikationen im Dateisystem angelegt werden, steht der file Input zur Verfügung.
Über Outputs werden die Logs dann normalerweise an zentrale logstash Instanzen geschickt, die die Daten zwischenspeichern, dann nach und nach anhand von Filtern aufbereiten und in Felder zerlegen und schlussendlich an Tools wie Elasticsearch weiterleiten, wo sie dann durchsuchbar und auswertbar gespeichert bleiben. Sie können auch an Monitoring Tools wie Icinga oder per Mail weitergeleitet werden.
Da logstash aber als gestandene Java Anwendung mehr Ressourcen verbraucht, als mancher Windows Host erübrigen kann, gibt es auch Alternativen. Mit Tools wie snare kann Windows beigebracht werden, Eventlogs via Syslog Protokoll zu verschicken. Wie Syslog Nachrichten angenommen werden können, wurde bereits in einem früheren Artikel dieser Serie beschrieben. Auch Lumberjack (inzwischen umbenannt in logstash-forwarder) unterstützt mittlerweile Windows und kann so Logfiles aus dem Dateisystem SSL gesichert an logstash verschicken.

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...

Was macht jetzt der logstash im logstash?

Eine kurze Anmerkung in eigener Sache: Um Terminkollisionen zu vermeiden, wird das Erscheinen neuer Artikel dieser Serie auf Montag Nachmittag verschoben.
In den bisherigen Artikeln dieser Serie habe ich erwähnt, dass logstash mit anderen Tools gemeinsam eingesetzt wird. Diese Verbindung ist so stark, dass einige davon, Elasticsearch und Kibana, als embedded Version im logstash .jar File mit ausgeliefert werden. Spricht man von einer logstash Installation, meint man damit normalerweise gleich mehrere logstash Instanzen und zusätzliche Tools. Wie es sich für freie Tools gehört, arbeitet logstash nämlich nicht nur mit den erwähnten Elasticsearch und Kibana, sondern noch mit vielen weiteren Tools zusammen, die diese beiden auch teilweise ersetzen können.
Genauer gesagt ist logstash nur ein Framework, das Plugins verwendet um diverse andere Tools miteinander zu verbinden und die Nachrichten am Weg aufzubereiten. Dabei werden viele Plugins mitgeliefert. Es ist aber verhältnismässig leicht, eigene Plugins zu schreiben. Welche Plugins mitgeliefert werden und wie die zu konfigurieren sind, findet man in der logstash Dokumentation. Dort sieht man auch schön die Aufteilung in die drei Stufen jeder logstash Instanz:

  • Input
  • Filter
  • Output

In der Dokumentation ist Codec noch als eigener Punkt erwähnt, dabei handelt es sich aber nicht um eine eigene Stufe, sondern wird nur gemeinsam mit einer der anderen Stufen verwendet. Die Syntax ist dlogstash_01abei immer ziemlich einfach und vor allem durchgängig gleich. Nur die Optionen unterscheiden sich und verändern sich auch teilweise von Version zu Version. Ein regelmässiger Blick in die Dokumentation ist deshalb bei Updates unbedingt empfehlenswert.
Input: Diese Plugins befördern Logs in die logstash Instanz. Das können passive Wege sein wie der bereits erwähnte syslog Input, der einen Port öffnet und wartet, bis dort Nachrichten ankommen, oder aktive, wie der file Input, der eine Datei überwacht und jede neue Zeile als ein neues Event verarbeitet.
Filter: Hier passiert die Magie, die logstash stark von Syslog Servern abhebt. Die Events werden verändert und aufbereitet. Das kann das Umformen eines Timestamp in ein einheitliches Format sein, das Auflösen einer IP Adresse in einen Hostnamen, oder, besonders wichtig, das Zerlegen der Nachricht in einzelne Felder. Mit dem grok Filter kann mithilfe von vorgefertigten Mustern und Regex Information aus Events klassifiziert werden, was in den erwähnten Feldern resultiert. Die Filter sind normalerweise für das Umformen und nur selten für das “Ausfiltern” also Verwerfen von ungewollten Nachrichten zuständig.
Output: Mit diesen Plugins wird gesteuert, an welche Tools logstash seine Information ausgibt. In den bisherigen Beispielen war das eine Elasticsearch Instanz. Es ist aber auch möglich, an Icinga zu schreiben, bestimmte Events per Mail zu verschicken oder sie an andere logstash Instanzen schicken.
Sehr oft wird logstash dazu verwendet, um Daten zu weiteren Instanzen oder Zwischenspeichern wie Redis weiterzuleiten. Eine Instanz hat dabei normalerweise nur eine Aufgabe. Grob kann man logstash in Shipper und Central einteilen, wobei die Shipper Daten sammeln und an einen Zwischenspeicher schicken. Von dort holt sie dann entweder ein weiterer Shipper (um z.B. Aussenstellen mit der Zentrale zu verbinden) oder der Central ab, der üblicherweise als einziger logstash in einem grösseren System Filter verwendet. Realisiert wird das mit getrennten Konfigurationsdateien, wobei man beim Start der jeweiligen Instanz eben die passende Datei angibt. Es ist also durchaus üblich, mehrere logstash Instanzen auf einem einzigen Host zu haben. Die Bezeichnung “Shipper” und “Central” oder auch “Indexer” hat sich in der Dokumentation so eingebürgert. Es handelt sich dabei nur um eine Umschreibung der konfigurierten Plugins und nicht etwa um eine eigene Einstellung in der Konfiguration oder gar eine andere logstash Version.
Sind in einer Instanz mehrere Inputs definiert, holt sich logstash Nachrichten von allen diesen Inputs. Sind mehrere Outputs definiert, wird an jeden dieser Outputs eine Kopie des gerade verarbeiteten Events geschickt. Da es keine Möglichkeit gibt, doppelte Events leicht wieder auszusortieren, sollte man sehr vorsichtig sein, wohin man Events sendet. Sind mehrere redundante Ziele vorhanden, wie z.B. mehrere Redis Instanzen, so definiert man die innerhalb eines einzelnen Outputs und logstash wählt beim Start dann eines dieser Ziele aus und sendet so lange dorthin, bis er nichts mehr annimmt und wechselt erst dann zum nächsten Ziel.
Besonders hilfreich ist das Klassifizieren der Daten in verschiedene Felder. Wer schon einmal Logs von Mailservern nach Informationen durchsucht hat, weiss, dass es nicht einfach bis unmöglich ist, zum Beispiel die Empfängeradressen aus jeder Logmeldung mit einem einzigen Shell Command auszulesen, vor allem wenn auch Filterdienste wie Spamassassin in das maillog schreiben. Mit logstash können je nach Art der Logmeldung unterschiedliche Filter angelegt werden und so ein Feld wie mail_recipient (die Namen sind frei wählbar) immer mit der Empfängeradresse befüllt werden. Bei der Auswertung mit Kibana kann dann nach dem Feld gefiltert oder Graphen anhand dessen gezeichnet werden.

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...

logstash – Die erste Schulung ist durch.

Die erste logstash Schulung bei Netways ist durch. Das Feedback war durchweg positiv aber auch konstruktiv. Auch wenn für den (Teilzeit) Franken ein “Passt scho'” als die positivste Gefühlsregung gilt, zu der er fähig ist und damit ausreichend wäre, so ist es für einen Trainer doch immer viel hilfreicher, wenn auch Verbesserungsvorschläge unter den Rückmeldungen sind.logstash_01
Für’s nächste Mal gibt es deshalb mehr vorgefertigte Übungsbeispiele, um die Zeit möglichst produktiv zu nutzen, falls die nächsten Teilnehmer wieder so gut sind, aber noch keine eigenen Logs haben sollten, die sie von logstash zerlegen lassen wollen.
Auch als Trainer lernt man nie aus, vor allem, wenn es so seltsame Effekte gibt wie den folgenden: Eine Logdatei voller Beispieldaten wird schön von grok und date Filtern abgearbeitet. Sobald aber Events aus dem letzten Oktober kommen, schreibt logstash Fehler und bearbeitet diese Events nicht. Auch ein Ändern der Beispieldaten bringt keine Erleuchtung. Immer, wenn das Log mit “Oct” beginnt, bricht der date Filter die Verarbeitung ab. Tauscht man es gegen “Okt” aus, streikt der grok. Suche in den offenen Issues von logstash bringt vorerst nichts, Anfrage im IRC Channel auch nicht. Des Rätsels Lösung war dann die “locale” des Systems. grok erwartet sich für Syslog Nachrichten die englische Schreibweise, aber der date Filter will das Datum in einem Datumsformat, das zu den Spracheinstellungen des Systems passt. Die locale Einstellung des date Filters löst dieses Problem.
Aber nicht nur knackige Probleme gilt es in der Schulung zu lösen. Auch den oft beschworenen “Boah, ey!” Effekt gibt es dort zu erleben. So waren alle Teilnehmer inkl. Trainer verblüfft, dass sich die Elasticsearch Instanzen auf den Schulungsnotebooks dank der hervorragenden Default Einstellungen gleich zu einem Cluster verbinden. An sich ist das zu erwarten, aber wenn man die Schulung an einem einzelnen Notebook vorbereitet, auf dem heftig virtualisiert wird und die multicast cluster node discovery nicht ganz so reibungslos funktioniert, rechnet man ehrlich gesagt nicht damit, dass sich die Notebooks im Schulungslan so problemlos zu einem Elasticsearch Cluster zusammenfinden.
Auf jeden Fall hat mir die Schulung viel Spass gemacht und ich hoffe, den Teilnehmern erging es ebenso. Das Feedback und einige neue Erkenntnisse werden sicher in die kommenden Schulungen einfliessen. Nur für den Fall, dass jemand noch mehr Motivation braucht, sich dieses wunderbare Tool näher bringen zu lassen und zu erfahren, was es mit date und grok auf sich hat.
Wann die nächste Schulung stattfindet und wie man sich dafür anmelden kann, erfährt man auf der Seite zu unseren logstash Schulungen.

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...

Der Klassiker: syslog -> logstash

Bevor es an den Aufbau neuer Features mit logstash geht, soll erst mal der übliche Vorläufer von logstash in Netzwerken ersetzt werden: Der gute alte Syslog Server.
Zu Syslog finden sich weiterführende Informationen in der Wikipedia, deshalb hier nur kurz umrissen: Syslog ist sowohl ein Protokoll, als auch der Name eines Tools, das dieses Protokoll benutzt, um Logs innerhalb eines Systems von Applikationen einzusammeln und in Logfiles zu schreiben und sie auch übers Netzwerk an andere Hosts zu schicken. Diese anderen Hosts sind normalerweise die eingangs erwähnten Syslog Server, die einfach mal alles an Logs sammeln, was ihnen präsentiert wird und in lokale Logfiles schreiben.logstash_01
Gegenüber Lösungen wie logstash ergeben sich bei Syslog vor allem 3 Probleme:

  1. Die Lösung skaliert nicht. Wenn ein Server nicht mehr mit dem Annehmen und Wegschreiben von Logs mitkommt, kann man ihn höchstens durch stärkere Hardware ersetzen. Irgendwann ist da aber Schluss.
  2. Die Logs liegen genau so am Syslog Server wie auf stand-alone Hosts auch. Also unstrukturiert. Durchsuchen und Auswerten verlangt normalerweise einiges an grep/awk oder Perl und Regex magic.
  3. Die Übertragung passiert normalerweise unverschlüsselt über UDP. Beides will man normalerweise nicht für kritische Logs. (Auch wenn Ableger wie rsyslog und syslog-ng da teilweise Abhilfe schaffen)

Punkt 1 und 2 kriegt man mit logstash sehr einfach in den Griff. Man kann mit logstash einen Syslog Server bauen, der Logs sowohl im klassischen Syslog Format vom syslog Tool, als auch von neueren Tools wie rsyslog, die auch über TCP und teilweise sogar verschlüsselt senden können, annehmen kann.

input {
  syslog {
    type => "syslog"
    port => 514
  }
}

Aus. Das war’s. Mehr ist nicht nötig und das ist sogar schon etwas mehr, als nötig ist. Der Port ist auch ohne Angabe auf dem Syslog Standard von 514, allerdings sowohl TCP, als auch UDP. Der type ist übrigens frei wählbar und wird nur später benutzt, um den Weg der Nachricht durch logstash zu planen. Er hat nichts damit zu tun, dass Daten im Syslog Format erwartet werden. Weitere Informationen zu den möglichen Optionen des Syslog Input gibt’s in der logstash Dokumentation.
Nochmal zusammengefasst reicht es, dem Quickstart aus dem ersten Beitrag dieser Serie zu folgen und den syslog Teil des obigen Beispiels zum input hinzuzufügen. Jetzt noch die IP Adresse des bisherigen Syslog Servers auf den logstash Server verschieben und fertig.
Zugegeben, natürlich war das Quickstart Beispiel nicht für eine Produktivumgebung gedacht. Dazu fehlt zumindest noch Ausfallsicherheit und die Meldungen werden immer noch ziemlich unstrukturiert abgelegt. Die zum Aufbereiten nötigen Filter können aber ebenso nach und nach hinzugefügt werden. Ziel dieses Artikels war ja, den Syslog Server zu ersetzen und auf weitere Verbesserungen vorzubereiten.
Was mehr Aufwand benötigt ist die gesicherte Übertragung der Syslog Nachrichten an den logstash Server. Mit syslog ist das sowieso nicht möglich. Mit rsyslog Sind aber auf jeden Fall Änderungen an der Konfiguration jedes sendenden Host nötig.
Wer das Beispiel einfach mal ausprobieren möchte und bisher keinen zentralen Syslog Server hatte, kann mit folgenden kurzen Codebeispielen andere Server zum Versand bringen.
syslog:

*.* @192.168.200.2

Wobei 192.168.200.2 hier die IP Adresse des logstash Servers ist. Der Eintrag ist eine Zeile aus /etc/syslog.conf auf den meisten Systemen. Danach muss syslog neu gestartet werden. Mit service syslog restart auf gängigen Linux Distributionen, sofern sie überhaupt noch syslog einsetzen und mit svcadm disable system-log ; svcadm enable system-log auf Solaris.
rsyslog:

*.* @@192.168.200.2:514

Wobei die doppelten @ dafür sorgen, dass die Übertragung über TCP stattfindet. Diese Zeile kann in eine eigene Datei in /etc/rsyslog.d gelegt werden.schulung_logstash
Es soll natürlich hier nicht verheimlicht werden, dass logstash auch eigene Möglichkeiten mitbringt, die Daten auf dem Host einzusammeln und an einen zentralen logstash Server zu schicken. Wie das geht, ist Inhalt eines späteren Artikels oder unserer logstash Schulungen.

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...

logstash – Der 15 Minuten Quickstart Guide

Da ich mich die letzte Zeit intensiv auf logstash Schulungen und – Consulting vorbereitet habe, liegt es nur nahe, dass ich auch zu diesem Thema blogge. Bei so zentralen Systemen ist es natürlich wichtig, sich intensiv damit auseinander zu setzen und viel Zeit zu investieren, um erstmal die Hintergründe und Zusammenhänge zu verstehen, damit man eine Installation planen kann, bevor man das erste Mal Code in die Hand nimmt. Prinzipiell ist das so richtig, aber es muss auch mal ok sein, einfach mal mit einem neuen, interessanten System rumzuspielen, bevor man sich intensiver damit beschäftigt, um erstmal ein gewisses Gefühl für die Arbeitsweise zu bekommen und weil es einfach Spass macht.

natural_logstashUnd genau dafür soll dieser Quickstart Guide sein. Zuvor aber dennoch ein paar Worte dazu, was logstash denn nun eigentlich ist und wozu man es verwenden kann und soll. Wer das schon weiss, darf auch weiter nach unten scrollen. Aber keine Sorge, weitere Infos über die Abläufe in einer logstash Installation kommen noch in dieser Blogserie. Genauso ein paar Beispiele, wie Logs von logstash aufbereitet werden können. Wer also keine Lust hat, sich mal kurz logstash zu installieren, muss nur ein wenig warten.

Jeder Computer und auch sonst fast jedes Gerät, mit dem man in der IT zu tun bekommt, schreibt Logfiles, wo besondere Ereignisse festgehalten werden. Das hilft nicht nur, aber insbesondere, beim Erkennen und Nachvollziehen von aufgetretenen Fehlern. Als Administrator steht man nun vor dem Problem, dass diese Logfiles auf den Systemen bleiben und man sich erstmal dorthin verbinden muss, um sie zu lesen. So bleiben oft kleinere Fehler, die grössere Ausfälle im Vorfeld ankündigen und helfen würden, diese zu verhinlogstash_01dern, unerkannt. Für diesen Fall bieten wir gerne Unterstützung mit Monitoring wie Icinga an. Wer aber nicht erst warten möchte, bis es kracht, sondern schon proaktiv handeln möchte, muss irgendwie an die Logfiles rankommen, ohne den halben Tag damit zu verbringen, sie von den Systemen abzuholen. Natürlich gibt es noch viele weitere Gründe, Logs zu sammeln, zu lesen und auszuwerten, aber das würde den Rahmen eines Einleitungsartikels sprengen. Es gibt bereits seit langer Zeit Lösungen wie logwatch oder syslog Server, die zumindest helfen, die Informationen aus Logfiles zu sammeln. Wozu dann logstash? Ein paar der Vorteile gegenüber herkömmlicher Lösungen sind:

  • logstash kann auf vielen verschiedenen Systemen ausgeführt werden und ist als Java (bzw. JRuby) Anwendung nicht auf ein paar Betriebssysteme beschränkt
  • logstash kann alle möglichen und unmöglichen Formate lesen. Syslog und Windows Eventlog sind naheliegend, aber auch über das Drupal dblog oder IRC können Nachrichten in logstash kommen. Gibt es keine Schnittstelle für einen Dienst, können auch beliebige Textfiles auf Systemen als Logfile angesehen und ausgewertet oder die Rückgabe beliebiger Programme gelesen werden.
  • logstash ist von vornherein darauf ausgelegt, hervorragend zu skalieren. Alle Komponenten können mehr oder weniger auf beliebig viele Server ausgebracht und miteinander verbunden werden. Teilweise als sehr einfach zu verwaltende loadbalancing und high availability cluster, teilweise einfach als redundante Instanzen, die nichts voneinander wissen und einfach jeweils nur einen Teil der zu verarbeitenden Daten erhalten. Und das, wie von Tools, die wir unterstützen, nicht anders zu erwarten, alles ohne Lizenzkosten. Wer dann noch freie Linux Distributionen einsetzt, wird eigentlich nur durch Anschaffungs- und Betriebskosten der Hardware in der Grösse der logstash Installation beschränkt.
  • logstash leitet Logs nicht einfach stumpf weiter, sondern zerlegt sie in Felder, die dann in der Auswertung genutzt werden können. Damit fällt die Regexbastelei zum Küren des grössten Spamempfängers anhand der Sendmail Logs weg, denn eine Information wie die Empfängeradresse kann schon beim Verarbeiten der Logs als eigenes Feld ausgewiesen werden, nach dem dann gefiltert oder mit dem dann Berechnungen angestellt werden können.

Jetzt aber wie versprochen die Kurzanleitung:

logstash wird als .jar File zum Download angeboten, das auch gleich ein paar andere der benötigten Tools in embedded Versionen enthält. Den Download findet man prominent unter http://logstash.net/ . Ausserdem muss Java installiert sein. logstash ist ziemlich unempfindlich, welche Java Version eingesetzt wird. In Tests hat OpenJDK-7 hervorragend funktioniert.

Als nächstes wird eine einfache Konfigurationsdatei namens logstash-quickstart.conf angelegt:

input {
  stdin {
    type => "stdinput"
  }
  file {
    path => "/var/log/messages"
    type => "syslog"
  }
}
output {
  stdout {
    codec => rubydebug
  }
  elasticsearch {
    embedded => true
  }
}

Dieses Beispiel muss mit einem User gestartet werden, der Leserechte auf /var/log/messages hat. Wer das nicht für einen Test möchte, kann den file Part einfach weglassen. Dieses Konfigfile lässt logstash Events aus /var/log/messages sowie von stdin annehmen und gibt sie auf stdout aus, speichert sie aber auch gleichzeitig in die im .jar File mitgebrachte Elasticsearch Instanz.

Gestartet wird logstash mit

java -jar logstash-1.3.3-flatjar.jar agent -f logstash-quickstart.conf -- web

Dann passiert erstmal nicht viel. Nach ein paar Sekunden erhält man eine Warnung, dass verwendete Plugins noch nicht als stabil gekennzeichnet sind, die man für einen Test einfach mal ignorieren kann. Dann wartet logstash auf neue Logmeldungen. Falls nicht zufällig eine neue Nachricht in /var/log/messages geschrieben wird, kann man auch einfach eine Testnachricht abschicken, die dann logstash durchläuft und aufgeschlüsselt wieder ausgegeben wird. Ohne weitere Konfiguration wird aber natürlich nicht viel aufgeschlüsselt, sondern die gesamte Nachricht im message Feld wieder ausgegeben. Ein paar zusätzliche Felder fügt logstash automatisch hinzu und der type wurde ebenfalls über die Konfiguration gesetzt.

[root@fenris ~]# java -jar logstash-1.3.3-flatjar.jar agent -f logstash-quickstart.conf -- web
Using milestone 2 input plugin 'file'. This plugin should be stable, but if you see strange behavior, please let us know! For more information on plugin milestones, see http://logstash.net/docs/1.3.3/plugin-milestones {:level=>:warn}
hello world
{
       "message" => "hello world",
      "@version" => "1",
    "@timestamp" => "2014-01-23T12:06:27.895Z",
          "type" => "stdinput",
          "host" => "fenris.int.netways.de"
}

“hello world” ist die eingetippte Testnachricht.

Um logstash zu beenden, kann Ctrl+C gedrückt werden. Aber zuvor lohnt sich ein Blick auf http://localhost:9292/index.html#/dashboard/file/logstash.json . Woah! Das ist Kibana. Das mitgelieferte Webinterface zur Analyse der gespeicherten Events.schulung_logstash

Und jetzt kommt der Clou: Die logstash Installation ist voll funktionsfähig und die gesammelten Events bleiben auch gespeichert, wenn man logstash beendet und später wieder neu startet. Ab hier geht es “nur” mehr darum, die Daten in mehr und brauchbare Felder zu zerlegen, sie von mehr Quellen zu sammeln, sie zwischen Hosts mit logstash Instanzen weiterzuleiten und die beteiligten Systeme zu tunen und zu skalieren. Dazu wird es Sinn machen, die embedded Versionen von Elasticsearch und Kibana als eigenständige Instanzen ausserhalb des .jar Files zu installieren und es um weitere Tools wie Redis zu ergänzen.

Wer jetzt schon überzeugt ist, dass logstash eine feine Sache ist, findet sich sicher etwas bei unseren logstash Starterpaketen oder logstash Schulungen . Wer nicht, hat noch ein paar Folgen dieser Blogserie Zeit, sich überzeugen zu lassen.

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...

Backup Quick 'n Dirty

Backuptools sind komplex und aufwändig. Das ist so und das wird sich auch so schnell nicht ändern. Wer sich auf sein Backup verlassen will, muss einfach Zeit, Aufwand und/oder Geld investieren. Was aber tun, wenn man keine hohe Sicherheit braucht, aber unter Umständen auf alte Stände des Systems / der Konfiguration zugreifen will? Weil vielleicht ein ausgefeiltes Backuptool vorhanden ist, aber ein Restore sehr umständlich wäre und man einen Abkürzung braucht? Geht sie – super! Geht sie nicht, gibt’s immer noch das eigentliche Backup.
Eine Möglichkeit wären vcs Systeme wie Git, aber auch die sind selten trivial in ihrer Bedienung – ausserdem müssen sie normalerweise dazu gebracht werden, einen aktuellen Stand eines Systems / einer Konfiguration zu sichern und das vergisst man leicht bzw. kann man es evtl nicht allen Usern zumuten. Ganz zu schweigen davon, dass man ja auch mal etwas sichern möchte, ohne, dass man dabei “anwesend” ist. Und nicht zuletzt sind vcs Systeme dafür gedacht, Textdateien wie Quellcode und Config zu sichern und nicht ganze Server.
Eine mögliche Lösung sind Tools wie Rsnapshot. Backup, das leicht zu bedienen ist, aber, oder weil es, auf viele Features verzichtet.
Rsnapshot ist sehr schnell eingerichtet und braucht beinahe keine Ressourcen.
Die Installation funktioniert in aller Regel über den Paketmanager der ausgewählten Distribution und die Konfiguration ist ziemlich selbst erklärend mit einigen Kommentaren in der Beispielkonfig, weshalb ich hier nicht weiter darauf eingehen möchte. Bedarf kann gern in den Kommentaren angemeldet werden, dann reiche ich gern einen Artikel dazu nach.
Kurz zusammengefasst erstellt das Tool eine Kopie des Dateisystems mit rsync und erstellt Kopien dieser Kopie mit Hilfe von Hardlinks. Dadurch benötigen nur die Dateien, die sich seit dem letzten Lauf geändert haben, tatsächlich Platz auf der Festplatte. Ein Restore funktioniert dann einfach via cp oder ähnlichen Bordmitteln. Aber bitte nicht mv, da dies die interne Struktur der Backups durcheinanderbringen kann.
Ein paar mehr Details sind für das weitere Verständnis allerdings noch hilfreich: rsnapshot kennt verschiedene Intervalle, die in der Konfiguration sortiert sind und immer vom Kürzesten zum Längsten genannt werden. Dabei ist es völlig unerheblich, wie die Intervalle benannt werden, wichtig ist, nur dass die Reihung kürzer -> länger immer eingehalten wird. Der Einfachheit halber hat es sich eingebürgert, sie nach Zeitspannen zu bennnen und sie ihrem Namen entsprechend auszuführen, also hourly stündlich, daily, täglich, etc. . Im Sinne einer einfacheren Lesbarkeit werde ich davon ausgehen, dass es genauso umgesetzt wird – ich bitte also um Verständnis, wenn ich “stündliches Backup” und nicht “am häufigsten ausgeführte Backupkonfiguration” schreibe. Ausserdem gehe ich davon aus, dass 24 hourly, 7 daily, 4 weekly, 12 monthly und 10 yearly aufgehoben werden sollen. Genauso gut könnte ich 6 hourly, 17 daily und 8 quonko aufheben, aber das wird jetzt schon klar sein.
rsnapshot wird nach der Konfiguration via cron aufgerufen und zwar immer in der Art rsnapshot [intervallname], wobei eben hourly stündlich, daily täglich, etc. ausgeführt wird. Anders ausgedrückt muss für jeden Intervall ein eigener Job eingerichtet werden.
Im internen Ablauf passiert bei jedem Dtündlichen ein rsync, das die zu sichernden Verzeichnisse nach hourly.0 unter dem angegbenen Zielpfad kopiert (hourly entspricht wieder dem frei wählbaren Intervallnamen). Ausserdem wird hourly.23 (wegen dem Beginn bei 0 gibt es natürlich kein hourly.24) gelöscht, hourly.22 via mv in hourly.23 umbenannt, hourly.21 in hourly.22, etc. Das passiert noch vor dem Ausführen des rsync, weshalb bereits davor kein hourly.1 mehr existiert. hourly.0 wird mithilfe von Hardlinks nach hourly.1 kopiert – erst dann findet der zuvor genannte rsync statt.
Bei einem Lauf mit rsnapshot daily wird daily.6 gelöscht, daily.5 in daily.6 umbenannt, etc. . hourly.23 wird in daily.0 umbenannt. Existiert zu diesem Zeitpunkt kein hourly.23, gibt’s auch kein neues daily. Das bedeuet auch, dass erst daily erstellt werden, wenn alle hourly existieren. Das gilt es zu bedenken, wenn man z.B. 96 hourly behalten will. Ausserdem ist somit jedes daily älter als jedes hourly, jedes weekly älter als jedes daily, etc. In der angenommenen Konfiguration könnten wir also alleine durch hourly und daily 8 Tage zurück.
Wirklich hilfreich werden tools wie rsnapshot aber erst, wenn man etwas länger daran herumspielt. Ein Problem ist zum Beispiel, dass bei jedem Lauf alle bereits erstellten Backups umbenannt werden. Sucht man ein bestimmtes Backup, so muss man ausrechnen, wie es aktuell heisst und hoffen, dass alle Sicherungen nur via cron angestossen wurden. Eine mögliche Abhilfe ist, sich einen Ordner anzulegen, in dem man Dateien hinterlegt, die nur für die Dauer eines Backuplaufs existieren und das Backup identifizeren. z.B /root/snap/mysql_coldbackup . Nach der Datei kann man dann den Zielordner durchsuchen (aber bitte nicht mit locate, sondern mit etwas, das den aktuellen Zustand des Filesystems überprüft 🙂 ). Man kann das auch automatisieren, in dem man durch cron unmittelbar vor jedem backup einen timestamp dort hinterlegen lässt. Es ist auch denkbar, gewisse Zustände so zu verewigen. z.B Softwareversionsstände im Laufe einer Migration (geht ebenfalls automatisiert, vor allem da die meisten tools beim Aufruf mit -V ihre aktuelle Versionsnummer ausgeben.) oder noch ausstehende Schritte. So habe ich mir angewohnt, vor grösseren Schritten, erst touch /root/snap/[namedesgroesserenschrittes] ; rsnapshot hourly && rm -f /root/snap/[namedesgroesserenschrittes] auszuführen. So kann ich, wenn was schief geht, leicht auf alte Konfig zugreifen, kann das aber durchaus öfter machen, da diese Backups durch die stündliche Rotation wieder rausfallen. Evtl. geht eines davon auf die Reise durch die weiteren Intervalle, aber das stört mich nicht weiter.
Dabei muss man natürlich bedenken, wie lange man die Backups aufheben möchte. Da rsnapshot die einzelnen Intervalle unabhängig voneinander rotiert, passiert es leicht, dass ein Zustand, der nur in einer einzigen Sicherung vorhanden ist, bei der stündlichen Rotation rausfällt. Möchte man, dass gewisse Dateien länger im Backup bleiben, gibt es leider keine Garantie dafür. Wenn alles glatt geht, sollte das Aufheben aber funktionieren, wenn man die Datei einen Intervall des Backupzyklus lang verfügbar macht, für das man es aufhält. Ist eine Datei also eine Woche lang auf dem Filesystem zu finden, hat man gute Chancen, sie in allen hourly, allen daily und mindestens einem weekly zu finden, bis die Rotation sie aus dem letzten weekly wirft. In unserem Beispiel also 5 Wochen und 1 Tag lang. Gefährdet wird diese Logik vor allem, wenn man ausgiebig Gebrauch von den oben erwähnten “händischen Backups” macht. Damit erhöht sich die Zeit, die ein Status bestehen muss, um ins daily überzugehen natürlich entsprechend.
Die yearly backups scheinen in den meisten Fällen überzogen, aber das ist aus meiner Sicht der beste Weg, einen Zustand dauerhaft zu bewahren. Dazu ein Beispiel aus der Praxis. Bevor ich eine grössere Migration beginne, in deren Rahmen ich rsnapshot einführe, lege ich die Konfiguration an und lasse, dem obigen Beispiel folgend, 24+7+4+12+10 mal folgenden Befehl laufen: rsnapshot hourly ; rsnapshot daily ; rsnapshot weekly ; rsnapshot monthly ; rsnapshot yearly. Das dauert nicht sehr lange und braucht nur minimal mehr Platz als eine einzige Kopie des zu sichernden Filesystems. Ab da beginne ich die normalen cron Läufe mit hourly stündlich, daily täglich… . So kann ich davon ausgehen, dass für die ganze Dauer der Migration und auch jedes spätere Mal, wenn ich zu diesem Kunden komme, die ursprüngliche Ausgangssituation im letzten yearly noch vorhanden ist.
Noch ein paar Worte der Warnung. Als Ziel wird rsnapshot ein Verzeichnis angegeben. Wenn dort ein anderes Filesystem, z.B. von einer USB Festplatte, gemountet ist und man diese entfernt, legt rsnapshot einfach in dieses Verzeichnis neue Backups an, womit man sich ganz schnell Festplatten anfüllen kann. Dieses Verhalten ist allerdings konfigurierbar. Falls das reguläre Backuptool das rsnapshot Zielverzeichnis inkludiert und nicht mit Hardlinks umgehen kann, wird man bald einen Backupadmin mit einer roten Kletzn (österr. für “Kopf”) im Büro stehen haben, weil man bei der obigen Konfig 24+7+4+12+10+1 mal den gesamten Platz des zu sichernden Filesystems wegkopiert. Das selbe gilt bei Netzwerkshares, etc. auf die man hinschreibt, sofern die nicht mit Hardlinks umgehen können. Aus dem gleichen Grund kann man auch nicht einfach via ssh oder ähnliches auf einen entfernten Server sichern. Um das hinzubekommen, muss man via rsync auf den Zielhost sichern und dort dann rsnapshot laufen lassen. Wer auf andere Hosts sichern, selbst auf dem selben Host die Backupkonfiguration verwalten und Backups auch noch verschlüsseln will, sollte sich evtl. duplicity und die vielen kleinen Tools, die einem das Leben damit deutlich einfacher machen, wie duply oder deja-dup ansehen. Eine Stolperfalle, in die man immer wieder gerne tappt, ist das Konfigfile, das Optionsname und Wert immer mit Tabulator getrennt verlangt und bei Zeilen, die Leerzeilen statt Tabs enthalten, Fehler wirft. Daher bietet es sich immer an, einen rsnapshot hourly Lauf nach Konfigänderungen zu machen.
Nicht zuletzt sollte man immer daran denken, Restores nur mit Kopien zu machen, da man Daten tatsächlich aus den Backups rausnehmen kann und so unter Umständen alle Kopien vernichtet. Umgekehrt muss man Backupsets, die man aus der Rotation entfernt (Pfade, die nicht mehr gesichert werden oder wenn man z.B. von 48 hourly auf 24 hourly umstellt) selbst löschen. Das nimmt einem rsnapshot nicht ab.

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...

S/MIME Emailsicherheit auf Android

Wer sich nach den Nachrichten der letzten Zeit nicht etwas mehr mit sicherer Kommunikation auseinander setzen will, sollte gleich ins Eck gehen und sich schämen. Für alle, die hier bleiben dürfen, gibt’s wieder einen Tip von mir, wie man einfach und gratis die eigene Privatsphäre besser schützt.
Der beste Weg, Nachrichten sicher zu übertragen ist, sie am eigenen Gerät zu verschlüsseln und sie erst am Gerät des Empfängers zu entschlüsseln. So muss man sich nicht darauf verlassen, dass jedes Netzwerkgerät (oder sogar Kabel) vor fremdem Zugriff gefeit ist. Ausserdem hat man so die Möglichkeit, Verschlüsselung über Kanäle zu nutzen, die eigentlich gar keine sichere Kommunikation anbieten, wie einige Instant Messenger zum Beispiel.
Für Email gibt es dafür 2 gängige Methoden: GnuPG (bzw. PGP) und S/MIME. Wobei GnuPG ganz ohne zentrale Stelle auskommt, während S/MIME verbreiteter ist. Da immer sowohl Absender, als auch Empfänger die gleiche Technologie unterstützen müssen, werde ich vorerst auf Letzteres eingehen. So wüsste ich zum Beispiel gar keine Möglichkeit, wie man GnuPG auf iOS verwenden kann.
Kurz zum technischen Hintergrund: S/MIME verwendet Zertifikate zur sicheren Kommunikation, von denen jeder User 2 Teile hat: Ein öffentliches und ein privates Zertifikat. Das Öffentliche dient nur zum Verschlüsseln und Überprüfen von digitalen Signaturen und kann überall verbreitet werden, während das private Zertifikat zum Verschlüsseln und Signieren von Nachrichten dient und geheim gehalten werden muss.
Wer eine signierte Nachricht erhält, kann mit dem öffentlichen Zertifikat überprüfen, ob sie wirklich mit dem dazugehörigen privaten Zertifikat signiert wurde, was so allerdings noch keinen Wert bietet, da der Empfänger keine verlässliche Information über den Besitzer des zugehörigen privaten Zertifikats hat. Um nun die Echtheit zu bestätigen wird das öffentliche Zertifikat vor der Verwendung von einer Certification Authority (CA) signiert, nachdem diese die Identität des Besitzers des Zertifikats überprüft hat. Vertraut der Empfänger der CA, dass sie Identitäten richtig überprüft, kann er anhand der Signatur der CA auf dem öffentlichen Zertifikat des Absenders bestätigen, dass dieser wirklich der ist, der er zu sein vorgibt.
Darin liegt auch der Nachteil von S/MIME gegenüber GnuPG. Man muss wieder einer zentralen Stelle uneingeschränkt vertrauen, dass sie 1. Identitäten richtig überprüfen kann und 2. ihr eigenes Zertifikat sicher schützen kann, damit sich nicht jemand eine Signatur auf seinem Zertifikat erschleicht. Ausserdem verlangen viele CAs verhältnismässig viel Geld für eine Signatur auf dem eigenen Zertifikat.
Die Entscheidung, welcher CA man vertraut, wird einem in gewissem Rahmen einfach abgenommen, da jedes Emailprogramm und jeder Browser eine Liste von CAs mitbringt, denen automatisch vertraut wird. Befindet sich eine CA nicht in dieser Liste, gibt es eine der bekannten Zertifikatswarnungen, dass die Echtheit nicht überprüft werden kann, die je nach Gesinnung des Herstellers mal mehr, mal weniger klar macht, dass die CA einfach noch nicht bekannt ist. Gewisse Softwarehersteller gehen dabei gerne so weit, solche Zertifikate als per se unsicher zu bezeichnen. Ein schönes Beispiel für: “Dein Dienst bringt mir keinen Profit, also bist Du auch sicher nichts wert.” Glücklicherweise kann man aber selbst entscheiden, welcher CA man vertraut und die öffentlichen Rootzertifikate der CA in das eigene Emailprogramm / Browser / Zertifikatsspeicher des OS importieren oder wieder löschen.
Eine Alternative zu den kommerziellen CAs stellt eine selbst aufgebaute CA dar, wobei man dann bei der Kommunikation mit fremden Partnern nichts gewonnen hat, denn wieso sollte der Empfänger der CA mehr vertrauen als einem selbst signierten Zertifikat? Oder eine der CAs, die auf eine Community mit einem WebOfTrust setzen, um Identitäten zu überprüfen. Die wahrscheinlich bekannteste solche CA ist CAcert.
Der grösste Haken an CAcert ist derzeit noch, dass ihre öffentlichen root Zertifikate noch nicht in Browsern und Emailprogrammen integriert sind, was regelmässig zu den oben erwähnten Zertifikatswarnungen führt. Importiert man sie also nicht selbst, werden Emails, die via CAcert gesichert sind, normalerweise vom eigenen Emailprogramm als “Nicht sicher” markiert.
Übrigens gelten S/MIME Zertifikate immer nur für einen bestimmten, nicht verlängerbaren Zeitraum. Anders als GnuPG Schlüssel, werden die Schlüssel beim erneuten Signieren komplett neu erstellt, weshalb man auch aubgelaufene Zertifikate immer aufbewahren sollte, da man sonst Nachrichten, die mit diesen alten Zertifikaten geschützt waren, nicht mehr lesen kann!
Soviel zum (sehr) kurzen Überblick zu S/MIME. Wie ich mich kenne, wird’s dazu sicher noch geben, in Zukunft.
Jetzt aber zum eigentlichen Thema, dem Verwenden von S/MIME auf Android. Da das Besorgen eines S/MIME Zertifikats den Rahmen dieses(!) Artikels sprengen würde, gehe ich davon aus, dass ein von CAcert signiertes Zertifikat vorhanden ist. Alternativ kann die Anleitung natürlich auch mit jedem anderen gültigen Zertifikat durchgeführt werden. Eventuell ist das Rootzertifikat der CA ja schon in Djigzo vorhanden, wodurch der gesamte Import desselben weg fällt.
Ich hatte zum ersten Mal zur Zeit von Android 2.3.6 Kontakt mit diesem System und damals war der E-Mail Client (zumindest auf Samsung Galaxy Geräten) mehr oder weniger zum wegschmeissen. Ich bin deshalb auf K-9 Mail umgestiegen, das man schön mit anderen Apps erweitern kann und so auch Unterstützung für GnuPG und S/MIME nachrüstbar war. Auf allen neueren Geräten habe ich dann K-9 verwendet, ohne den nativen Client eines Blickes zu würdigen. Für S/MIME benutze ich Djigzo.
Djigzo, wie viele andere S/MIME fähige Clients, lässt das Verschicken von signierten und verschlüsselten Mails nur dann zu, wenn es selber der signierenden CA vertraut. Um das bei CAcert zu schaffen, holt man sich die Rootzertifikate (Class 1 und Class 3, Djigzo sollte mit PEM und DER Format gleichermassen klar kommen) und importiert sie in Djigzo. Dazu hilft es nicht, CAcert anzusurfen, das Zertifikat anzuklicken und gleich mit Djigzo zu öffnen – das geht nur mit persönlichen Zertifikaten, die man zum Verschlüsseln verwendet. Leider wird man darauf nicht hingewiesen, sondern kann ganz normal importieren und wundert sich dann, warum der CA noch immer nicht vertraut wird. Stattdessen lädt man die Rootzertifikate auf das Android Gerät und wählt dann in der Ansicht der Rootzertifikate “Importieren”.
djigzo
Danach kann man eigene Zertifikate und öffentliche Zertifikate von Kommunikationspartnern importieren. Entweder ebenfalls erst auf das Gerät legen und dann via Menü importieren, oder, hier geht das ja, z.B. von einem eigenen Webserver herunterladen. Dazu exportiert man die Zertifikate erst von einem Programm, in dem man sie bereits verwendet und schützt sie (das wird beim Export automatisch verlangt) mit einer ausreichend sicheren Passphrase.
Wenn alles geklappt hat, das Zertifikat importiert und der signierenden CA vertraut wird, belohnt das Djigzo mit einem grünen Häkchen.
netways-key
Im Gegensatz zu z.B. iOS kann man gleich mehrere Zertifikate in einer Datei importieren und auch mehrere Zertifikate für eine E-Mailadresse aktiv haben. Allerdings muss man in den Settings/Account settings/Select signer… erst festlegen, welches Zertifikat denn zum signieren benutzt werden soll.
Um jetzt sichere Emails zu verschicken, gibt man die eigenen Zugangsdaten zum Mailserver in Djigzo nochmal an (in den Settings, allerdings wird man beim ersten Öffnen gleich auf den entsprechenden Assistenten verwiesen) und verwendet danach die Funktion “Compose Message“. Empfängt man verschlüsselte Mails in K-9, erscheint das Mail leer mit einem Anhang namens “smime.p7m”. Den kann man in Djigzo öffnen, wo er dann gleich entschlüsselt wird.
Öffentliche Zertifikate, die der Kommunikationspartner ja zum Verschlüsseln braucht, verschickt man am Einfachsten, indem man ein signiertes Mail an den entsprechenden Partner sendet.
Übrigens verwendet Djigzo eine eigene Passphrase, die die eigenen Zertifikate schützt, selbst wenn jemand ins Android Gerät einbrechen sollte.
Zugegeben, die S/MIME Integration in iOS (wenn man die entsprechenden Zertifikate erstmal installiert hat, und damit leben kann, dass man nicht darauf aufmerksam gemacht wird, ob man verschlüsselt schickt oder nicht, geschweige denn, wählen könnte, ob) ist im Alltag komfortabler und die GnuPG Integration via APG in K-9 deutlich besser, aber die Lösung mit Djigzo ist durchaus praktikabel. Es gibt sicher noch andere Möglichkeiten, S/MIME auf Android zu verwenden, aber bisher bin ich recht gut damit gefahren. Da S/MIME Zertifikate nur immer für relativ überschaubare Zeiträume ausgestellt werden, erhält man auch bald Übung im Zertifikatshandling. 😉

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...

Feind liest mit! Oder doch nicht?

Vielen ist ja E-Mail mittlerweile zu langsam geworden. Ausserdem ist es ja so was von Web 1.0. Also muss was schnelleres her. ICQ kennt schon fast keiner mehr und IRC kennen viele (leider) nur mehr aus Gruselgeschichten von anno dazumal. Wer also nicht nur vom Handy aus kommunizieren und sich damit zwischen teuren (und schon fast wieder retro-chicen) SMS und dem sicherheitstechnischen Alptraum Whatsapp entscheiden will, dem bleibt ausser dem Apple-only iMessage nur ein (Instant) Messenger.
Da es ja viele verschiedene Messenger Dienste und Protokolle gibt (nun doch wieder ICQ, AIM, Jabber über eigene Server, Jabber über Facebook, Jabber über Gtalk, Skype, …) empfiehlt sich eine Multimessenger Applikation wie Pidgin oder sein Mac OS X Ableger Adium. Darin kann man dann Instant Messenger (und IRC, für alle, die noch wissen was gut ist) Accounts sammeln und alle Kontakte, die geekig genug sind, mehrere Zugänge zu haben, zu einem Meta-Kontakt zusammenfassen. Der Messenger kümmert sich dann um die Auswahl des Dienstes.
Bleibt nur das Problem, dass die Daten ja wieder über die Server eines der Anbieter laufen und der zumindest theoretisch mitlesen könnte. Ausgenommen, man betreibt seinen eigenen Jabber/IRC Server, aber es dürfte doch noch User geben, die das nicht tun. Wer dennoch sichergehen will, dass Instant Messages geheim zwischen Sender und Empfänger bleiben, sollte sich OTR ansehen. Kurz zusammengefasst wird die Message im Client mit dem öffentlichen Schlüssel des Empfängers verschlüsselt und erst der Schlüsseltext über das Messagingprotokoll verschickt. Aus Sicht des Messengerdienstes sieht es aus, als würde man selbst den verschlüsselten Text eintippen, weshalb es völlig wurscht ist, über welchen Dienst man sendet. Dabei kann die Identität des Empfängers zuvor durch Vergleichen des Fingerprints überprüft werden. Kennt man schon? Hat hier jemand PGP|GnuPG|S/MIME gesagt? Ganz oberflächlich betrachtet funktionieren die Lösungen aus Anwendersicht gleich. Der vielleicht wichtigste Unterschied ist, dass der Fingerprint nur zur Überprüfung der Verbindung verwendet wird, die Nachrichten selbst werden nicht signiert. Es kann also im Nachhinein nicht mehr sicher festgestellt werden, wer eine Nachricht verschickt hat.
Adium hat ein OTR Plugin bereits an Bord, für Pidgin gibt’s eines bei den Cypherpunks. Dass beide Kommunikationsteilnehmer einen OTR fähigen Messenger brauchen, versteht sich. Es gibt auch diverse OTR fähige Messenger für Smartphones, aber da besteht derzeit wohl noch etwas Aufholbedarf.
Grösster Nachteil: Viele Messenger (man denke an Facebook oder Google Talk) sind in alle mögliche Software integriert und auch meist aktiv, ohne, dass man sie extra anwerfen müsste. Zwar ist OTR eine hervorragende Möglichkeit, sogar über den Facebook Chat sicher zu kommunizieren, aber wer mehrere Messenger für Facebook aktiv hat, wird leicht mal zugespammt, wenn nicht alle OTR fähig sind und den gleichen Schlüssel haben. Wenn ein Messenger eine Antwort nicht entschlüsseln kann, fordert er meist die Nachricht noch mal an, mit anderem Schlüssel verschlüsselt oder gar nicht verschlüsselt. So entsteht ein netter Pingpong Effekt und jeder Messenger erhält die Nachricht x-mal, mal verschlüsselt lesbar, mal verschlüsselt unlesbar, mal entschlüsselt. Das kann einfach umgangen werden, in dem man wirklich alle Messenger abdreht, die man im Moment nicht benutzt oder sich mit den Kommunikationspartnern auf ein Protokoll bzw. einen Dienst einigt, der nicht in jedem zweiten Smartphone integriert ist.
Noch ein Tip aus der Praxis: Die Messenger legen Protokolle über geführte Unterhaltungen an und die sind normalerweise im Klartext. Wer also sichergehen will, dass die Informationen nicht irgendwann von der Festplatte gekratzt werden, sollte den Messenger (oder das OTR Plugin) so konfigurieren, dass OTR gesicherte Unterhaltungen nicht gespeichert werden.

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...