Minimale Rechte und persönliche Accounts zur Administration

Icinga 2
Nachdem in unserer letzten “Icinga 2”-Schulung die Diskussion aufkam wie man Icinga 2 am besten mit minimalen Rechten konfiguriert und administriert, will ich mich dieser Thematik mal annehmen. Dies wird zwar anhand des Beispiels Icinga 2 auf CentOS 7 sein, aber lässt sich so auf jeden Dienst anwenden, der in Konfigurationsdateien verwaltet wird.
Ausgangsbasis
Die Ausgangsbasis stellen immer die Rechte dar, die durch das Package bei der Installation vorgegeben werden. Diese sollen unverändert bleiben, da sie sonst bei einem Update wieder auf den Standard des Packages zurückgesetzt werden. Als zweites gehen wir mal davon aus, dass eine Anmeldung als unpriviligierter Benutzer mit einem persönlichen Account möglich ist, wobei egal ist ob dieser lokal angelegt ist oder aus einem zentralen Verzeichnisdienst kommt, und dass dieser zur Administration genutzt werden soll.
Bei Icinga 2 sehen die Rechte nach der Installation folgendermaßen aus:

  • Auf dem Hauptverzeichnis /etc/icinga2 hat root alle Rechte, die Gruppe icinga darf lesen und browsen, alle anderen haben keine Rechte.
  • Auf die Dateien und Unterverzeichnisse hat der Benutzer icinga alle Rechte, die Gruppe icinga darf lesen und Verzeichnisse browsen, alle anderen haben keine Rechte.
  • Die Ausnahme bildet die Datei /etc/icinga2/init.conf, bei der die Benutzerrechte auf root liegen, aber auch nicht editiert werden sollte.

Zusätzlich zu den Dateirechten brauchen wir zur Administration Befehle wie systemctl reload icinga2.service um Icinga 2 neuzustarten oder auch icinga2 daemon -C zum Validieren der Konfiguration. Die Systemkommandos können nur als root ausgeführt werden, die Icinga-Kommandos als root oder icinga. Der Benutzer icinga ist allerdings als Benutzer gedacht unter dem der Dienst läuft und hat daher keine Benutzerumgebung, Kommandos können mit sudo aber trotzdem mit seinen Rechten ausgeführt werden.
Ein unpriviligierter Account kann nun noch nicht mal die Konfiguration lesen oder auch nur durch die Verzeichnisse navigieren, den Dienst nicht steuern oder Icinga-Kommandos absetzen. Dies können wir auf zwei Arten lösen. Methode 1 sind Gruppenrechte, Methode 2 ACLs, beides angereichert um eine Prise sudo um Kommandos unter anderen Rechten auszuführen.
(mehr …)

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

OSDC 2016: More for your datacenter stack

We need more coffee – the first talk of day 2 directly kicked off with automation and challenges. We are using Foreman at NETWAYS and it helps me on a daily basis to deploy development boxes with Opennebula. So it was interesting to find out about insights and challenges by Julien Pivotto with Automating a R&D lab with Foreman: What can be hard?.


Sadly the second talk about Interesting things you can do with ZFS by Allan Jude & Benedict Reuschling was at the same time – again one for the conference archive.


Decisions decisions. Mesos and the Architecture of the New Datacenter by Jörg Schad or Hybrid Cloud – A Cloud Migration Strategy by Schlomo Shapiro. I guess I’m one of those devops hipsters going for Mesos. Although I hear that its implementation can be tricky (hi Sebastian) we’re using it at NETWAYS and I wanted to learn more about it. Especially since Mesosphere recently announced DC/OS.


Ingesting Logs with Style sounds like a swiss army knife presentation style. Logs always remind me of the days when there was not Logstash or Graylog around, just some unacceptable expensive Splunk license and your own central syslog server plus some custom handmade scripts. Pere gave an awesome outlook on what’s coming with Elastic Stack 5.0 including hist sports activities as live demos.


Everyone knows about Docker. Everyone uses it in production already? Or at least tried to until the company’s security team stepped into? Inspecting Security of Docker formatted Container Images to find Peace of Mind provided insights on the most often asked questions when it comes to production deployments.
Right after lunch David Schmitt gave an interesting Introduction to Testing Puppet Modules. Being a developer and writing tests? Meh. The least exciting part right after the documentation bits. Though tests will make your life easier especially with Puppet modules ensuring they won’t break. The talk’s topic also reminds me of Tom de Vylder maintaining the Icinga puppet modules and insisting on rspec tests on every single PR – chapeau 🙂


Coming from MariaDB Colin Charles provided tipps and tricks on Tuning Linux for your Database.


An Introduction to Software Defined Networking (SDN) by Martin Loschwitz or Bareos Backup Integration with Standard Open Source Tools with Maik Aussendorf?


Finally the last talks for this years OSDC. We already learned about Puppet and Salt, now it is time for Kaiten Zushi – Chef at Goodgame Studios by Jan Ulferts. Florian Lautenschlager with Chronix – A fast and efficient time series storage based on Apache Solr was again my favourite for the conference archive.
 

Thank you and see you in 2017

The conference archive will be made available in the next couple of days. Save the date – 16.-18.5.2017 🙂
PS: Everything is a freaking DNS problem!

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

Compliance Reports in Foreman

Foreman Logo
Ein Steckenpferd von mir ist Security und ich habe mich daher schon vor einer ganzen Weile auch mit OpenSCAP beschäftigt, um umgesetzte Sicherheitsmaßnahmen auch zu visualisieren und regelmäßig auf Compliance zu prüfen. Mein damaliger Workflow bestand dann noch aus Cronjobs, Monitoringplugin und selbstgestricktem Dateiupload, doch nun nimmt mir auch hier Foreman die Arbeit ab.
Doch einmal langsam und von vorne: Was ist OpenSCAP eigentlich? SCAP ist die Abkürzung für Security Content Automation Protocol. Dieses baut auf bereits etablierten Standards auf um sicherheitsrelevante Software-Fehler und Konfigurationsprobleme darzustellen und bringt diese in eine Form, die eine automatisierte Auswertung ermöglicht. OpenSCAP ist eine OpenSource-Implementierung dieses Standards und liefert beispielhafte Richtlinien für verschiedene Linux-Distributionen und Anwendungen wie Java oder Firefox, Werkzeuge zur Überprüfung und Anpassung der Richtlinien an Firmenvorgaben.
Diese Werkzeuge macht sich das Foreman-Plugin OpenSCAP zu Nutze um Compliance Reports zu integrieren. Prinzipiell besteht es aus drei Komponenten. Das eigentliche Plugin erweitert Foreman um die Möglichkeit SCAP-Regelwerke im Datastream-Format hochzuladen, im Anschluss darin enthaltene Profile Hostgruppen zuzuweisen, eine Anleitung für den Administrator zu erzeugen und zu guter Letzt die Reports der Systeme anzuzeigen. Die Kommunikation läuft hierbei über den Smart Proxy, der ebenfalls durch ein Plugin erweitert wird, das den Download der Profile und den Upload der Reports ermöglicht. Zur Konfiguration der Systeme kommt Puppet zum Einsatz wofür ein entsprechendes Modul zur Verfügung steht.
Das ganze sieht dann so aus:
OpenSCAP-Guide in Foreman
Foreman-OpenSCAP-Guide
OpenSCAP-Report in Foreman
Foreman-OpenSCAP-Report
Ergebnis inklusive Lösungsvorschlag im OpenSCAP-Report in Foreman
Foreman-OpenSCAP-Result
Wie man allerdings auf den Bildern sieht habe ich mir keine Mühe gegeben mein eigenes Demosystem weiter abzusichern. Nun könnte ich entweder die angemeckerten Missstände beheben oder ich nehme mir aus dem OpenSCAP-Projekt die SCAP-Workbench und schneidere mir mein eigenes Profil zurecht. Auch dies geht sehr simpel und graphisch, nur wenn neue Definitionen und Checks geschrieben werden müssen wird es komplizierter.
SCAP-Workbench
Wer sicherstellen will, dass seine Systeme bereits von Anfang an sicher installiert sind und auf Fedora, Red Hat Enterprise Linux, CentOS oder ein anderes Derivat setzt, kann hierfür sogar ein Plugin für den Installer Anaconda nutzen.
Anaconda-OpenSCAP
Mir hätte damals ein solcher Satz an Werkzeugen viel Arbeit abgenommen, daher hoffe ich zumindest einigen der Lesern etwas an die Hand gegeben zu haben um eine weitere Anforderung an ihre Umgebung zu lösen. Neben diesem gibts auch noch weitere Plugins die Foreman um ein vielfaches mächtiger machen, einen Teil davon auch in unserer Foreman-Schulung.

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Es trifft mich wie ein Blitz …

Java-Logo
… heute früh meldete Heise Security einen seit ca. neun Monaten bekannten Exploit, der sich als besonders kritisch einstuft.
Zu diesem Zeitpunkt war ich gerade in einem Meeting mit Bernd und bin fast aus allen Wolken gefallen, als Sebastian mit dieser Nachricht in der Tür stand.
Ich bot an dieser Meldung genauer auf den Grund zu gehen, da ich selber begeisterter Java Entwickler bin und mich wie vermutlich auch viele von euch direkt oder eben auch indirekt mit Java und dem erweiterten Stack tagtäglich beschäftige.
Im Netz kursiert seit dem 6. November der folgende Artikel, dessen Autor Herr Stephen Breen, sehr genau, fast schon spielerisch beschreibt, wie dieser Exploit denn genau funktioniert.
Er schreibt dort im wesentlichen über die in Java schon seit Version 1.1 verfügbare ‘Serializable’ Schnittstelle, die es dem Programmierer ermöglicht fertig instanziierte Java Objekte über das Netzwerk zu senden oder auch von Festspeichern zu lesen. Diese Klasse ist allerdings nur der kleinere Teil des Übels, genauer gesagt ist es die Methode “InvokerTransformer” der “Apache CommonCollections API” die hier über die “Java Reflections API” es einem möglichen Angreifer hier Kinderleicht macht seinen Schadcode auf dem Zielsystem zur Ausführung zu bringen.
Nun könnte man fast meinen das einen das ja nicht wirklich betrifft, da muss ich euch leider enttäuschen und das sogar berechtigterweise.
Folgende Szenarien um das Problem im wesentlichen zu konkretisieren:

  • Servlet Container sowie Application Server verwenden diese API, wie im Artikel zu lesen ist, auch um Cookies und HTTP Header zu lesen. Das ist im ersten Moment noch nicht so kritisch, nur werden heutzutage auch viele Cross-Site-Request-Forgery und andere Angriffe dazu verwendet die Systeme der Wahl erfolgreich zu attackieren.
    Ein Angreifer könnte versuchen über entsprechende HTTP Header mit Cookie Payload ein bösartiges Objekt seiner Wahl einzubetten, das wiederum wenn auf dem Ziel System einmal angekommen, im ersten Moment Zugriff auf die der dort laufenden Anwendung zu Verfügung stehenden Klassen nutzen kann. Hier ist es dann bereits ein leichtes dem Application Server bzw. ServletContainer einen separaten URL Context ( zum Beispiel unter http://application.yourdomain.com/nasty-little-exploit ) mit anderen Funktionen unterzujubeln. Et Voila der Schaden wäre bereits immens.
    Auch ein simpler Download als Injected Java Objekt könnte hier den Rest des Ziel Systems mit entsprechenden Schadcode über eine Art Bootstrap Job infizieren.
    Um dem vorher gehenden Beispiel noch einmal etwas Würze zu verleihen, einen bereits bestehenden URL Context einer großen Bank könnte so manipuliert werden, um Kundendaten abzugreifen. Auch hier wäre der Schaden nicht zu ermessen.
  • Die Software von Drittanbietern ist davon mit unter auch betroffen. Vor allem wenn sie die oben genannte Schnittstelle verwendet oder sogar muss. Hier sollte man schnell Handeln aber auf keinen Fall das Problem ignorieren. Allein anzunehmen das hier ja bereits verschlüsselte Kommunikation stattfindet, schütz vor diesem Exploit nicht.
  • Ich schlage ihnen daher vor, den Rat des Autors zu beherzigen und diese Schnittstelle aus der Apache CommonCollections API zu verbannen, allein die Nutzung der Application einzustellen um anschließend ein komplettes Refacturing der Anwendungen vorzunehmen verursacht vermutlich sehr hohe Kosten und ist hier mit der Gefahr verbunden sich einem weiteren Exploit zu schaffen, jedoch recht schnell geschehen. Schnelle Änderungen schaffen immer wieder neue Bugs und vermutlich auch neue noch unbekannte ZeroDay Vectoren.

Dem einen oder anderen von euch stellen sich hier vermutlich schon die Nackenhaare auf, daher wollen wir nun lieber über die Deeskalation bzw. möglichen Lösungen kümmern, was gilt es nun zu tun!?

  • Evaluieren ob die Apache CommonCollections API auf dem eigenen Systemen existiert.
  • Prüfen ob die eingesetzte Java Software von dieser Gebrauch macht.
    • Wenn dem so ist, sollte die Anwendung aus der DMZ entfernt werden, das blockieren der von außerhalb erreichbaren Ports genügt im ersten Moment bereits.
    • Wenn dem nicht so ist, dann Schwein gehabt.
  • Sofern die betroffenen Anwendungen ermittelt werden konnten, sollten folgende Punkte abgearbeitet werden.
    • Test der Anwendung in isolierter Umgebung ( Docker kann hierbei recht hilfreich sein ) mit der Apache CommonCollections API. Wobei vor Beginn die org/apache/commons/collections/functors/InvokerTransformer.class bereits aus der API entfernt sein sollte.
      Wenn es hier nichts zu beanstanden gibt und die Application auch ohne diese Schnittstelle zu laufen scheint, kann diese wieder in den Betrieb überführt werden.
    • Sollte die Anwendung nicht korrekt funktionieren, wird empfohlen diese unter Vorbehalt nur den eig. Mitarbeitern zur Verfügung zu stellen, sollte es sich bei der Anwendung allerdings, um eine des Kunden handeln, sieht es da schon etwas schwieriger aus, wobei sich vmtl. kein Kunde den damit einhergehenden Gefahren gerne ausgesetzt sieht.
      Hier sollte dem Kunden angeraten werden, die Application bis zu einem erfolgreichen Security Audit vom Netz zu nehmen.

Weitere Lösungsansätze sind derzeit noch nicht bekannt, wir versuchen euch aber entsprechend auf dem Laufenden zu halten.
Nützliche Links:

Link Inhalt
http://www.heise.de/security/meldung/Zero-Day-Alarm-fuer-viele-Server-mit-Java-2913605.html Heise Security Artikel
http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ der Exploit im Detail
https://commons.apache.org/proper/commons-collections/javadocs/api-release/org/apache/commons/collections4/functors/InvokerTransformer.html Javadoc zum betroffenen Interface
https://github.com/frohoff/ysoserial das daraus entwickelte Framework für Penetration Tests
https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19117/Oracle-JRE.html Java CVE – Übersicht

OSMC 2015: Der Countdown läuft – nur noch 21 Tage

Dr. Ralf C. Staudemeyer berichtet von “Icinga network security monitoring”

OSMC? Was soll das denn sein und wer sind die netten Menschen in diesen Videos? Die Open Source Monitoring Conference (kurz: OSMC) ist die internationale Plattform für alle an Open Source Monitoring Lösungen Interessierten, speziell Nagios und Icinga. Jedes Jahr gibt es hier die Möglichkeit sein Wissen über freie Monitoringsysteme zu erweitern und sich mit anderen Anwendern auszutauschen. Die Konferenz richtet sich besonders an IT-Verantwortliche aus den Bereichen System- und Netzwerkadministration, Entwicklung und IT-Management. Und die netten Menschen, die Ihr in unseren Videos zur OSMC seht, gehören dazu. 2015 wird die OSMC zum 10. Mal in Nürnberg stattfinden.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

Jetzt neu: OpenVPN auf der AKCP SecurityProbe

akcp securityprobe 5e standard
Für alle AKCP SecurityProbes gibt es ab der Firmware 405J jetzt das OpenVPN Feature.
Mittels Wizzards lässt sich die OpenVPN-Verbindung nun im Handumdrehen über das Webinterface einrichten. AKCP setzt bei den Standards auf: peer Authentication, digitale Zertifikate und eine starke Verschlüsselung mit 256 Bit.
Für Anwendungsfälle mit eingeschränkter Bandbreite wie Remote-Monitoring über GSM, wird die Tunnelung von UDP unterstützt.
Die SecurityProbe eignet sich von daher als großer Ableger (mehr Sensoren, mehr Sensorports, ggf. Kameras) gegenüber der Geräte HWgroup Ares und Sequioa Argon. Für den Betrieb via GSM benötigen Sie noch das separate Modem.
Die neue Firmware ist ab sofort auf der AKCP-Website erhältlich.
Fragen? Wir helfen gern. Nehmen Sie doch mit uns Kontakt auf, wir helfen Ihnen sehr gern weiter.

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

Things done wrong: Custom Packages

Homer Simpson
Als Consultant begegne ich öfter Konzepten jeglicher Art, sei es das ich sie erstellen darf oder mich bei der Umsetzung an diese halten muss. Besonders wenn letztere unkommentiert als Firmenrichtlinie hinzunehmen sind, komme ich oft nicht mehr aus dem Kopfschütteln raus. In diesem Blogpost will ich nun anfangen mit solchen Konzepten abzurechnen und werde wohl immer wieder neue Themen folgen lassen. Ich werde hierbei keine Kundenbeispiele direkt übernehmen sondern Beispiele mischen um es noch weiter zu überspitzen. Auch soll sich natürlich niemand angegriffen fühlen, wenn sein Konzept ähnlich aussieht, denn meist lässt es sich mit historisch gewachsen begründen. Aber vor allem will ich Probleme aufzeigen, die durch die Konzepte erstehen und dazu anregen solche veralteten Konzepte auf den Prüfstand zu stellen.
Das erste Thema, das ich aufgreifen möchte, ist das Thema Softwareinstallation. Die meisten Projekte und Administratoren haben mittlerweile eingesehen, dass lokale Installation aus dem Quelltext-Archiv nicht mehr zeitgemäß ist. Darum liefern Projekte oftmals auch direkt Pakete aus oder stellen zumindest die dazu nötigen SPEC-Files bereit. Die Gründe hierfür sind meist Nachvollziehbarkeit, geringerer Aufwand, kein Kompiler auf dem System, kein mühsames Ermitteln von Abhängigkeiten, etc. Daher existieren viele Konzepte für das Paketieren von Software, welche nicht vom Distributor ausgeliefert wird. Genau mit diesen möchte ich mich beschäftigen.
Nun auf welche Vorgaben trifft man häufig?
* Selbst paketierte Software soll in ein bestimmtes Verzeichnis installiert werden
* Die Software soll einem speziellen eigenem Benutzer gehören
* Alles soll aus einem einzelnen Paket kommen
* Das Paket soll schon die fertige Konfiguration enthalten
* Pakete müssen parametrierbar sein, da je nach Umgebung andere Pfade, Benutzer, etc. verwendet werden sollen.
Mit diesen Vorgaben möchte ich mich nun im Folgenden auseinandersetzen.
Das Argument selbst paketierte Software in ein eigenes Verzeichnis zu installieren ist üblicherweise Sicherheit. Dieser Mythos hält sich erstaunlicherweise und ich suche den Sicherheitsgewinn ähnlich verzweifelt wie den Yeti oder Nessie. Vielleicht lässt sich hier noch entsprechend argumentieren wenn das Verzeichnis mit speziellen Mount-Optionen als separate Partition eingehängt ist. Aber die Optionen, die einen wirklichen Sicherheitsgewinn bieten wie ACLs oder das Abschalten gewisser Optionen wie das Ausführen von Dateien, Uid-Flags, Devices, werden hier meist nicht genutzt. Zudem könnten diese meist besser und gezielter eingesetzt werden, wenn das Paket in Standardpfaden installiert ist und nur gewisse Verzeichnisse ausgehängt werden, zum Beispiel für temporäre Daten.
Gefährlich wird dies meist in Kombination mit der Vorgabe alles einem bestimmten Benutzer zu übereignen. Eigentlich ist ein Benutzername völlig egal. Benutzer unter denen ein Dienst läuft sollten sich aber üblicherweise nicht am System anmelden können und auch nicht auf schreibend auf ihre Konfiguration oder gar Binärdateien zugreifen können. Die Vorgabe kommt meist daher, dass der Benutzer dann allerdings zur Administration verwendet wird statt administratives und Dienstkonto zu trennen. Kann der Dienst nun seine Konfiguration schreiben, eröffnet dies viele Möglichkeiten für Exploits, denn es hat meist seinen Grund warum ein Dienst mit einem unpriviligierten Benutzer läuft. Noch besser wird es wenn der Benutzer den Dienst mittels sudo als root starten darf und Startskript, in dieses eingebundene Dateien oder Binärdateien verändern kann, damit sind in Sekunden die Rechte ausgeweitet, also genau das Gegenteil vom Ziel der Vorgabe erreicht.
Auch andere Sicherheitskonzepte wie SELinux werden durch die verbogenen Pfade schnell unwirksam, denn ohne die entsprechenden Dateikontexte greift die Policy nicht mehr. Der Aufwand Pakete so umzubiegen und dann weiterzupflegen, insbesondere wenn auch Python-, Perl- oder ähnliche Pfade umgebogen werden, ist dann üblicherweise auch so groß, dass Updates seltener gemacht werden als wenn die Software ohne weiteren Aufwand bezogen werden könnte. Auch dies setzt die Sicherheit weiter herunter.
Natürlich gibt es auch Konzepte, die den Aufwand gering halten, wie die von Red Hat eingeführten Software Collections, trotzdem muss immer noch selbst Aufwand betrieben werden. Der Aufwand ist dann besser darin investiert ein Konzept zu erstellen, welches dem Administrator der Zusatzsoftware erlaubt entsprechende Befehle mit sudo aufzurufen und Konfigurationsdateien über ACLs zu editieren, Logdateien zu lesen, …
Die Vorgaben zusätzliche Dateien oder angepasste Konfigurationen schon mit dem Paket mitzuliefern sind zwar machbar, erhöhen aber die Komplexität weiter und es lässt sich schwerer nachvollziehen woher Dateien ursprünglich kommen. Zusätzliche Dateien sollten also in eigene Pakete, Konfigurationen wenn man nicht auf eine Konfigurationsmanagementlösung setzen möchte in ein eigenes Konfigurationspaket. Über Befehle wie rpm -qf lässt sich dann nachprüfen aus welchem Paket eine Datei kommt, mit rpm -qi erhält man Informationen wie die Bezugsquelle und rpm -qV zeigt welche Dateien nachträglich verändert wurden.
Die Anforderung Pakete parametrierbar zu machen finde ich besonders seltsam, da es beim Paketieren nicht nur darum geht Software nicht auf dem System zu übersetzen, sondern auch Nachvollziehbarkeit in allen Aspekten zu schaffen. Da sich nie ausschließen lässt, dass ein anders gesetzter Parameter die ausgeführte Software beeinflusst, geht hierdurch für mich viel Nachvollziehbarkeit verloren. Diese möchte man besonders beim Updaten haben um Probleme auszuschließen.
Ich hoffe zum Nachdenken angeregt zu haben und Argumentationsgrundlagen für entsprechende Konzepte geliefert zu haben. Die nächsten Konzepte, die ich bei Gelegenheit betrachten möchte, sind das Benutzer- und Softwaremanagement und danach fällt mir bestimmt noch weiteres ein, wenn Interesse besteht. Und wer sein Konzept von mir zerpflückt haben möchte oder eins geschrieben braucht, ich bin natürlich ebenso käuflich wie die Kollegen. 😉

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Store passwords like a boss

Wer eine Web-Anwendung, die zwecks Authentifizierung Passwörter speichert, betreibt, der sollte sich – zwecks Sicherheit – Gedanken machen, welche kryptologische Hashfunktion die Anwendung zwecks Speicherung verwendet – schließlich soll bspw. ein eventueller Datenklau nicht gleich die betroffenen Konten vollständig kompromittieren.
Hintergrund: Wer ein Passwort (im Klartext) kennt, der gibt es einfach an der entsprechenden Stelle ein und hat Gewalt über das entsprechende Konto. Wer “nur” einen Hash des Passwortes hat, muss letztgenanntes erst via Brute-Force mühsam erraten.
Um letztgenannte Methode zusätzlich zu erschweren – und damit weniger attraktiv zu machen, habe ich folgende PHP-Funktion geschrieben:

function hashPasswordLikeABoss($password) {
    if (CRYPT_SHA512 !== 1)
        throw new Exception('This platform doesn\'t support the algorithm `CRYPT_SHA512\'');
    if (false === ($salt = openssl_random_pseudo_bytes(12)))
        throw new Exception('Failed at openssl_random_pseudo_bytes()');
    $salt = sprintf(
        '$6$rounds=%d$%s',
        mt_rand(50000, 100000),
        str_replace('+', '.', base64_encode($salt))
    );
    if ($salt !== substr(
        $hashed = crypt($password, $salt),
        0,
        strlen($salt)
    ))
        throw new Exception('Failed at crypt()');
    return $hashed;
}

Erklärung

Zuerst wird überprüft, ob der zu verwendende SHA512-Algorithmus von der ausführenden Plattform überhaupt unterstützt wird.
Danach werden via openssl_random_pseudo_bytes() 12 zufällige Bytes für den Salt angefordert. (Das kann ebenfalls fehlschlagen.)
Aus denen werden daraufhin 16 – dank base64_encode(). Dieser Funktionsaufruf dient hauptsächlich dazu, nur die für den Salt zulässigen Zeichen a-zA-Z0-9./ übrig zu lassen. Lediglich eventuelle `+’-Zeichen müssen noch durch Punkte ersetzt werden.
Um noch einen drauf zu setzen, werden zwischen 50000 und 100000 Runden verwendet – statt standartmäßig 5000.
Daraufhin wird der mit sprintf() zusammen gebaute Salt – zusammen mit dem Passwort – an crypt() übergeben und es wird überprüft, ob das Resultat mit dem übergebenen Salt beginnt, was für einen Erfolg spricht.
Zuletzt wird das gehashte Passwort zurückgegeben.

Fazit

Ob das die NSA von irgendwas abhält, kann ich nicht beurteilen – gegen den random (bad) Guy dürfte es aber allemal reichen.

Alexander Klimov
Alexander Klimov
Developer

Alexander hat 2017 seine Ausbildung zum Developer bei NETWAYS erfolgreich abgeschlossen. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der...

Lebenslange Garantie auf AKCP Basisstationen

securityprobe5e
Wussten Sie schon? AKCP gewährt auf alle Basisstationen, also AKCP SensorProbe2, SensorProbe4 und SensorProbe8 sowie die SecurityProbe5ES und die SecurityProbe5ESV lebenslange Garantie. Dies gilt für alle Basisstationen, die nach dem 1. Juli 2012 verkauft wurden (offizielle Mitteilung lesen). Sensoren und Zubehör haben bei AKCP nach wie vor 1 Jahr Herstellergarantie. Falls Sie Ihre Basisstation vor dem 01.07.2012 gekauft haben, gibt es ein Austauschprogramm; dieses gewährt die Lieferung eines fehlerfreien Gerätes außerhalb der Garantie für 50% vom Listenpreis (Bedingungen). Hört sich nicht nur super an, ist es auch – bei den wenigen Rückläufern die wir von AKCP-Hardware haben hat das bisher wunderbar geklappt.
Fragen? Hier helfen wir Ihnen gerne weiter!
Verpassen Sie keine Angebote mehr, abonnieren Sie noch heute unseren Shop-Newsletter (eine E-Mail im Monat).

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

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...