Schlagwortarchiv: Planet

Tag für den Ubuntuusers.de Planeten.

Roundcube mit PGP-Unterstützung

4 Antworten

Vor Kurzem wurde Roundcube Webmail[1. Roundcube Webmail] in Version 1.2.0 veröffentlicht. Zu einer der Neuerungen zählt die Unterstützung von PGP. Dabei hat man die Wahl zwischen der client-seitigen Verschlüsselung, basierend auf der Browser-Erweiterung Mailvelope und der server-seitigen Variante mittels Enigma-Plugins.

In diesem Artikel stelle ich beide Varianten kurz vor und zeige einige Punkte auf, die beim Einsatz zu beachten sind.

Zu Beginn noch einmal kurz zur Erinnerung: OpenPGP verwendet asymmetrische Verschlüsselung[2. Asymmetrische Verschlüsselung], bestehend aus einem privaten und einem öffentlichen Schlüssel. Dabei gilt, dass der private Schlüssel unbedingt vor unberechtigtem Zugriff zu schützen ist.

Enigma-Plugin

Das Enigma-Plugin ist bereits Bestandteil von Roundcube 1.2.0. Aleksander Machniak beschreibt in seinem englischsprachigen Blog die Installation und Nutzung des Plugins.[3. Enigma plugin (PGP encryption)]

Das Plugin befindet sich demnach bereits auf dem gleichen Server, auf dem auch die Roundcube-Installation läuft. Besitzt man selbst die vollständige Kontrolle über diesen Server, ist die Nutzung des Enigma-Plugins eine komfortable Lösung.

In meinem Fall läuft der Server, welcher die Roundcube-Installation hostet, jedoch bei einem Hosting-Provider. Zwar habe ich root-Zugriff auf diesen Host, doch besitze ich nicht die vollständige Kontrolle über diesen Server. Es besteht die Möglichkeit, dass beim Provider ein Zugriff auf meinen Server und damit auch auf meinen privaten Schlüssel erfolgen kann.

Mir persönlich ist das Risiko der Kompromittierung meines privaten Schlüssels bei dieser Variante zu groß. Daher scheidet sie für mich aus.

Mailvelope

Mailvelope[4. Mailvelope Webseite] stellt über eine Browser-Erweiterung eine client-seitige OpenPGP-Verschlüsselung für Webmailer bereit. Es existieren Erweiterungen für Chrome und Firefox. Die Schlüssel werden dabei im Benutzerverzeichnis von Chrome bzw. im Profilordner von Firefox gespeichert.[5. Mailvelope – Wo werden meine Schlüssel gespeichert?] Die Chrome-Einstellung „Nutzungsstatistiken und Absturzberichte automatisch an Google senden“, sollte man jedoch besser deaktivieren. Andernfalls könnten im Falle eines Absturzes Speicherinhalte mit privaten Schlüsseln an Google gesendet werden.

Verschlüsselt man die Festplatte mit der Installation, in der sich der private Schlüssel befindet, ist dieser zusätzlich bei Verlust oder Diebstahl des Endgeräts geschützt.

Der Vorteil dieser Variante liegt in jedem Fall darin, dass sich die Schlüssel auf einem Endgerät befinden, über das der Besitzer in der Regel die vollständige Kontrolle hat. Gerade wenn die Roundcube-Installation bei einem Hosting-Provider betrieben wird, ist diese Variante daher in meinen Augen vorzuziehen.

Fazit

Dass Roundcube nun zwei Varianten zur Nutzung von OpenPGP-Verschlüsselung unterstützt, finde ich grundsätzlich positiv. Für beide genannten Varianten gibt es sinnvolle Einsatzszenarien.

In jedem Fall sollte man für einen konkreten Anwendungsfall abwägen, bei welcher Variante der private Schlüssel besser geschützt ist.

Für mich persönlich habe ich beschlossen, dass keine der beiden beschriebenen Varianten für mich in Frage kommen. Die Variante mit dem Enigma-Plugin scheidet für mich aus, da mein Mailserver bei einem Hosting-Provider betrieben wird und ich nicht die vollständige Kontrolle über den Host habe.

Die Variante mit Mailvelope kommt für mich nicht in Frage, da es mir nicht gefällt, dass die Schlüssel im Webbrowser gespeichert und verwaltet werden. Ich besuche mit meinem Webbrowser täglich dutzende Webseiten und nutze verschiedenste Webdienste. Dabei besteht grundsätzlich das Risiko, dass mein Webbrowser durch Malware kompromittiert wird. Mir persönlich ist die Gefahr zu groß, dass dabei auch mein privater Schlüssel kompromittiert bzw. entwendet wird.

Meinen E-Mail-Client verwende ich hingegen ausschließlich zum Lesen und Schreiben von E-Mails. Die Angriffsfläche ist hier wesentlich kleiner und das Risiko geringer, dass mein privater Schlüssel kompromittiert wird.

Erstellung eines Yum-Repositories

Schreibe eine Antwort

Nachdem ich im Artikel „Lokaler Spiegelserver für CentOS, Fedora und RHEL“ beschrieben habe, wie man Paketquellen auf den eigenen Server spiegeln kann, möchte ich in diesem Artikel dokumentieren, wie man ein Yum-Repository erstellt, um darüber z.B. eigene RPM-Pakete zur Verfügung zu stellen.

Auch für diesen Artikel gilt, dass es keine Schritt-für-Schritt-Anleitung ist. Weiterführende Informationen findet man unter den Links am Ende des Artikels oder in der manpage des jeweiligen Programms.

Voraussetzung dafür ist, dass wie beim lokalen Spiegelserver ein Webserver läuft, über welchen das Repository ausgeliefert werden kann. Darüber hinaus muss das Programm createrepo installiert sein, welches über das gleichnamige Paket bereitgestellt wird.

Für das eigene Yum-Repository wird ein Verzeichnis erstellt, welches vom Webserver ausgeliefert werden kann. Unter CentOS, RHEL und Fedora kann dies z.B. wie folgt erfolgen:

:~# mkdir /var/www/html/custom-rpms

In dieses Verzeichnis werden die RPM-Pakete kopiert, welche man über dieses Repository bereitstellen möchte. Anschließend wechselt man in das Verzeichnis und erstellt durch den Aufruf von createrepo die erforderlichen Meta-Daten.

:~# cd /var/www/html/custom-rpms
:~# createrepo --database /var/www/html/custom-rpms

Damit ist die Erstellung des Yum-Repositories bereits abgeschlossen.

Ergänzend kann man noch eine *.repo-Datei erstellen, um die Verwendung des Repository zu vereinfachen.

Quellen und weiterführende Links

Konfiguration eines einfachen Git-Servers

5 Antworten

Git ist ein freies Versionsverwaltungssystem für Dateien. In diesem Artikel wird die Konfiguration eines einfachen Git-Servers dokumentiert, der von Entwicklern genutzt werden kann, um ihren Code ein- bzw. auszuchecken.

Der Zugriff auf den hier beschriebenen Git-Server erfolgt ausschließlich über SSH. Die öffentlichen SSH-Schlüssel der Entwickler müssen in der Datei authorized_keys hinterlegt werden, bevor diese auf den Server zugreifen können. Doch ein Schritt nach dem anderen.

Installation von Git

Zuerst wird Git selbst auf dem Server installiert. Dies kann je nach verwendeter Distribution mit einem der folgenden Kommandos erledigt werden.

Für CentOS, Fedora, RHEL, etc.:

sudo yum install git

Für Debian, Ubuntu und Derivate:

sudo apt-get install git

Die benötigten Abhängigkeiten werden dabei von der Paketverwaltung selbstständig aufgelöst.

Git-Benutzer erstellen und SSH-Zugriff einrichten

Für die Verwendung des Git-Servers wird ein eigener Benutzeraccount erstellt. In diesem Beispiel wird dafür der Benutzer „git“ angelegt. Der Name ist jedoch frei wählbar.

Anschließend wird im HOME-Verzeichnis dieses Benutzers die Datei ~/.ssh/authorized_keys angelegt, in welche die öffentlichen SSH-Schlüssel der Benutzer eingefügt werden, welche den Server später verwenden sollen.


:~# useradd git -m
:~# su git
:~$ cd
:~$ mkdir .ssh && chmod 700 .ssh
:~$ touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys

Ein leeres Git-Repository erstellen

Um ein neues/leeres Git-Repository zu erstellen, meldet man sich als „git“-Benutzer an und führt die folgenden Befehle aus:

mkdir verzeichnis.git
cd verzeichnis.git
git init --bare
Initialisierte leeres Git-Projektarchiv in /home/git/verzeichnis.git/

Fertig. Damit wurde ein Git-Repository erzeugt, welches von anderen Rechnern für Push- und Pull-Operationen genutzt werden kann.

Hinweis: Für die Erstellung weiterer Repositories muss die obige Prozedur wiederholt werden.

Zusätzliche Absicherung des Git-Servers

Bisher können Anwender, deren öffentlicher SSH-Schlüssel in der Datei authorized_keys des Git-Servers hinterlegt ist, sich via SSH am Server anmelden und bekommen eine Login-Shell. Dies ist evtl. nicht in jedem Fall gewünscht. Daher wird im Folgenden beschrieben, wie man den Git-Server härten kann.

Um ein Login via SSH zu verhindern, gleichzeitig aber die Ausführung von Git-Operationen zu erlauben, kann eine andere Shell für den Git-Benutzer gesetzt werden. Ob die dafür erforderliche Shell bei der Installation von Git bereits mit installiert wurde, kann mit folgendem Kommando überprüft werden:

which git-shell

Ist die git-shell installiert, liefert das Kommando den Installationspfad zurück. Dieser Pfad wird der Datei /etc/shells hinzugefügt.

Um nun die Login-Shell für den Benutzer „git“ zu ändern, wird folgendes Kommando mit root-Rechten ausgeführt.

sudo chsh -s git-shell git

Repository auf einem Client nutzen

In diesem Abschnitt beschreibe ich, wie ein Repository von einem einfachen Git-Server auf einem Client genutzt werden kann. Dabei verwende ich folgende Werte für die Umgebung.

  • FQDN des einfachen Git-Servers: git.example.com
  • Repository-Name: verzeichnis.git

git-clone via SSH-Protokoll

$ git clone ssh://git@git.example.com/home/git/verzeichnis.git

Repository als remote hinzufügen

Ich habe häufig den Fall, dass ich lokal auf meinem Client bereits ein Git-Repository habe, welches ich in das Repository auf meinem einfachen Git-Server pushen möchte. Dazu füge ich dies als remote wie folgt hinzu:

git remote add git-example ssh://git@git.example.com/home/git/verzeichnis.git

Dabei ist git-example ein Name, der mich daran erinnert, auf welchem Server das Remote-Repository liegt.

Quellen und weiterführende Informationen

Lokaler Spiegelserver für CentOS, Fedora und RHEL

4 Antworten

Durch die Nutzung eines lokalen Spiegelservers lassen sich Softwarepakete im lokalen Netzwerk bereitstellen. Dies schont die Internetverbindung und spart damit Bandbreite und evtl. Kosten.

Dieser Artikel beschreibt und dokumentiert die Einrichtung eines lokalen Spiegelservers für CentOS, Fedora und RHEL. Er bietet jedoch keine Schritt-für-Schritt-Anleitung. Für detaillierte Informationen wird auf die Quellen am Ende des Artikels sowie auf die manpages der einzelnen Kommandos verwiesen.

Konfiguration des Spiegelservers

Für den Betrieb eines lokalen Spiegelservers müssen ein Webserver sowie die CLI-Programme reposync und createrepo auf dem Host installiert werden, welcher als Spiegelserver dienen soll.

Hinweis für RHEL: Bei Verwendung von RHEL könnten nur jene Paketquellen gespiegelt werden, für welche der Spiegelserver eine gültige Subskription besitzt. Sollen auch solche Paketquellen gespiegelt werden, für die der Host keine Subskription besitzt, ist der Einsatz des kostenpflichtigen Satellite Servers erforderlich.

Diese Pakete befinden sich in der Regel in den Paketquellen, welche standardmäßig zur jeweiligen Distribution gehören. Für CentOS/RHEL können die Pakete zum Beispiel mit den folgenden Befehlen installiert werden:

$ sudo yum groupinstall "Einfacher Webserver"
$ sudo yum install yum-utils createrepo

Verwendet man bereits eine Fedora-Version mit dem YUM-Nachfolger DNF, so können die Pakete wie folgt installiert werden:

$ sudo dnf groupinstall "Web Server"
$ sudo dnf install yum-utils createrepo

Für eine Minimalkonfiguration des Webservers ist es erforderlich, den FQDN des Hosts als ServerName in der Datei /etc/httpd/conf/httpd.conf zu setzen.

Verwendet man die Hostfirewall, so ist der Zugriff auf den Webserver in dieser noch freizugeben.

$ sudo firewall-cmd --add-service http

Im nächsten Schritt wird unterhalb des Webserver-Wurzelverzeichnisses ein Verzeichnis erstellt, in dem zukünftig die gespiegelten Repositories abgelegt werden.

sudo mkdir /var/www/html/repomirror

Nun können mit reposync Pakete aus Online-Quellen auf den Spiegelserver heruntergeladen werden:

$ sudo reposync --gpgcheck -l --repoid= --download_path=/var/www/html/repomirror --downloadcomps --download-metadata -n

Die benötigte Repo-ID kann der ersten Spalte der Ausgabe von sudo yum repolist entnommen werden. Mit dem Parameter -n wird nur die aktuellste verfügbare Paketversion heruntergeladen.

Möchte man bspw. das base-Repository von CentOS spiegeln, so geschieht dies mit dem Kommando:

$ sudo reposync --gpgcheck -l --repoid=base --download_path=/var/www/html/repomirror --downloadcomps --download-metadata -n

Dadurch wird im Verzeichnis /var/www/html/repomirror das Unterverzeichnis base erstellt.

Damit die lokale Paketquelle nun von anderen Servern im lokalen Netzwerk genutzt werden kann, müssen noch die Metadaten mit Hilfe des folgenden Befehls erstellt werden. Beispiel für das base-Repository aus CentOS:

# cd /var/www/html/repomirror/base
# createrepo -v /var/www/html/repomirror/base/ -g comps.xml

Um den Abgleich der Paketquellen und die Erstellung der Metadaten zu automatisieren, kann folgendes Skript über den Cron-Dienst ausgeführt werden. Hier sind lediglich noch die REPO-ID und der Download-Pfad für die entsprechenden Variablen zu definieren.
#!/bin/bash
#
# Beschreibung: Skript zur Synchronisierung des RHEL-Repositories
# auf dem Spiegelserver
# Autor: Joerg Kastning <joerg(Punkt)kastning(aet)uni-bielefeld.de>

LOG="/var/log/do_reposync.log"
REPOID=" "
DOWNLOADPATH=" "

echo \# `date +%Y-%m-%d` - START REPOSYNC \# > $LOG

reposync --gpgcheck -l --repoid=$REPOID --download_path=/var/www/html/$DOWNLOADPATH --downloadcomps --download-metadata -n >> $LOG

echo \# `date +%Y-%m-%d` - END REPOSYNC \# >> $LOG
echo \# `date +%Y-%m-%d` - START CREATEREPO \# >> $LOG

cd /var/www/html/$DOWNLOADPATH/$REPOID
createrepo -v /var/www/html/$DOWNLOADPATH/$REPOID -g comps.xml >> $LOG

echo \# `date +%Y-%m-%d` - END CREATEREPO \# >> $LOG

exit 0

Erzeugung einer *.repo-Datei

Um die Paketquellen auf dem Spiegelserver zu verwenden, müssen diese auf dem Client bekannt gemacht werden. Dies geschieht zum Beispiel, indem auf dem Client eine *.repo-Datei im Verzeichnis /etc/yum.repos.d/ angelegt wird. Der Aufbau dieser Datei wird am Beispiel des CentOS-Repositories base demonstriert:

[base]
name= CentOS-$releasever - Base (local)
baseurl=http://FQDN/repomirror/base/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

Legt man diese Datei auf dem lokalen Spiegelserver in einem Verzeichnis ab, welches über den Webserver erreichbar ist, kann sie von einem Client mit dem folgenden Kommando importiert werden:

# yum-config-manager --add-repo http://FQDN/repomirror/DATEINAME.repo

Besonderheit bei Verwendung von SELinux

Bei Verwendung von SELinux, müssen die Dateien noch mit dem Attribut httpd_sys_content_t ausgestattet werden. Für Dateien in /var/www/html geschieht dies mit:

restorecon -R -v /var/www/html/*

Quellen und weiterführende Links

Bash-Skript zur Aktualisierung einer Roundcube-Installation

Schreibe eine Antwort

In diesem Artikel möchte ich euch ein kleines Bash-Skript vorstellen, mit dem die Aktualisierung von Roundcube gesteuert werden kann.

Es führt ein Backup der Roundcube-Installation inkl. der dazugehörigen MySQL-Datenbank durch, lädt das TAR-Archiv der neuen Version herunter und aktualisiert die existierende Version.

Das Skript habe ich auf GitHub Gist unter der GPLv3 veröffentlicht. Ihr dürft es also gern unter den Bedingungen der GPLv3 verwenden, ändern und in eigene Projekte einbauen. Es kann auch am Ende dieses Artikels als ZIP-Archiv heruntergeladen werden.

Um das Skript nutzen zu können, müssen die vier Variablen am Anfang des Skripts definiert werden:

# Variablen
INSTALL_PATH=" " # Pfad zur Roundcube-Installation
RC_DB_NAME=" " # Name der zur Roundcube-Installation gehörenden MySQL-Datenbank
PACKAGE_URL=" " # Download-URL der akutellen Roundcube-Version
MYSQL_ROOT_USER=" " # MySQL-Benutzer mit Root-Rechten auf der Roundcube-Datenbank

Anschließend muss das Skript noch mit dem Befehl chmod a+x updating_roundcube.sh ausführbar gemacht werden.

Nun kann das Skript zur Aktualisierung der Roundcube-Installation ausgeführt werden. Getestet habe ich das Skript heute, um meine Roundcube-Installation von Version 1.0.8 auf Version 1.0.9 zu aktualisieren.

Downloads:

2017-03-25_updating_roundcube.zip

Support-Subskriptionen von SUSE und RedHat

3 Antworten

Nachdem ich an dieser Stelle bereits ausführlich über das kommerzielle Angebot Ubuntu Advantage berichtet habe, möchte ich in diesem Artikel kurz die Support-Subskriptionen von SUSE und RedHat vorstellen.

Die Subskriptionen

Beim SUSE Linux Enterprise Server (SLES) sowie dem RedHat Enterprise Linux (RHEL) handelt es sich um kommerzielle Produkte, welche nur mit einer gültigen Subskription verwendet werden dürfen.

Mit einer Subskription erhält man neben dem Recht, das erworbene Enterprise Linux verwenden zu dürfen, auch Zugriff auf Software-Paketquellen und darin enthaltene Updates für das Betriebssystem und enthaltene Software. Darüber hinaus umfassen die Subskriptionen Zugang zu Wissensdatenbanken und zu technischem Support. Für letzteren legen die einzelnen Subskriptionen auch das jeweilige Service-Level-Agreement fest.

Im Unterschied zu Ubuntu Advantage umfassen die in der folgenden Tabelle dargestellten Subskriptionen keine Verwaltungs-Werkzeuge, wie z.B. das von Canonical angebotene Landscape. Diese können sowohl bei SUSE, als auch bei RedHat zusätzlich erworben werden.

Die folgende Tabelle bietet eine Übersicht über die gängigen Support-Subskriptionen für SLES und RHEL:

SLES StandardSLES PriorityRHEL StandardRHEL Premium
Subskription für1-2 Sockets oder 1-2 VMs1-2 Sockets oder 1-2 VMs2 Sockets, 1 physischer Server oder 2 VMs2 Sockets, 1 physischer Server oder 2 VMs
Software Upgrades & UpdatesJaJaJaJa
Anzahl Supportanfragenunbegrenztunbegrenztunbegrenztunbegrenzt
ZugangChat, Telefon und E-MailChat, Telefon und E-MailWeb und TelefonWeb und Telefon
Verfügbarkeit12x524x78x524x7
Reaktionszeiten
Stufe 12 Std.1 Std.1 Geschäfts-Std.1 Std.
Stufe 24 Std.2 Std.4 Geschäfts-Std.2 Std.
Stufe 31 Werktag4 Std.1 Werktag4 Std.
Stufe 41 Werktag1 Werktag2 Werktage8 Std. initial / 2 Werktage ongoing
Listenpreis pro Jahr670 EUR1.250 EUR700 EUR1.139 EUR

Die in der Tabelle enthaltenen Informationen beziehen sich auf die bei Veröffentlichung dieses Artikels aktuellen Angaben der Distributionen.

Die dargestellten Subskriptionen gelten für je einen physischen Server mit 1-2 CPU Sockets oder 2 VMs. Besitzt man einen physischen Server mit mehr als 2 CPU-Sockets muss eine Subskription mehrfach erworben werden, um diesen Server abzudecken. Besitzt ein Server bspw. 4 CPU-Sockets, muss die Subskription für diesen Server zweimal erworben werden. Möchte man die benötigte Anzahl der Subskriptionen für virtuelle Maschinen bestimmen, so lautet die Formel Anzahl VMs / 2 = Anzahl benötigter Subskriptionen.

Bei den Subskriptionen für virtuelle Maschinen spielt es dabei keine Rolle, ob diese mit Hilfe von VMware, Microsoft Hyper-V, XEN oder KVM betrieben werden.

Ab einer bestimmten Menge VMs ist es kostengünstiger statt Subskriptionen für einzelne VMs solche einzusetzen, welche das gesamte virtuelle Datacenter abdecken:

SUSE für hochdichte VirtualisierungsumgebungenRed Hat Enterprise Linux for Virtual Datacenters
StandardPriorityStandardPremium
Gültig für1-2 Sockets mit unbegrenzter Anzahl virtueller Maschinen1-2 Sockets mit unbegrenzter Anzahl virtueller Maschinen1-2 Sockets mit unbegrenzter Anzahl virtueller Maschinen1-2 Sockets mit unbegrenzter Anzahl virtueller Maschinen
Listenpreis für 1 Jahr1.330 EUR2.490 EUR2.192 EUR3.507 EUR

Die in der obigen Tabelle dargestellten Subskriptionen gelten jeweils für einen physischen Host, auf welchem virtuelle Maschinen ausgeführt werden. Zum Beispiel müssen für einen VMware vSphere-Cluster bestehend aus drei physischen Hosts mit je 1-2 CPU Sockets dann drei der entsprechenden Subskriptionen erworben werden. Auch hier gilt wieder, besitzt ein Host mehr als 2 CPU-Sockets, muss die jeweilige Subskription entsprechend mehrmals für diesen Host gekauft werden, bis die Gesamtzahl der CPU-Sockets pro Host abgedeckt ist.

Der Vorteil dieses Subskriptions-Modells liegt darin, dass hiermit beliebig viele VMs in einem virtuellen Datacenter betrieben werden können. Wird das virtuelle Datacenter jedoch um einen physischen Host erweitert, muss für diesen ebenfalls eine Subskription erworben werden, obwohl weiterhin die gleiche Anzahl VMs darauf ausgeführt wird. Je nach Kostenbetrachtung kann dies einen Nachteil darstellen.

Die folgenden Diagramme stellen den Break Even der jeweiligen Subskriptionen dar. Sie wurden für die Verwendung eines virtuellen Datacenters bestehend aus 3 Hosts mit jeweils 1-2 CPU Sockets berechnet.

Bei den in diesem Artikel verwendeten Preisen handelt es sich um Listenpreise. Beim Kauf von Subskriptionen über einen Fachhändler können je nach Umfang der Bestellung meist noch Rabatte gewährt werden.

Neben den hier betrachteten Subskriptionen existieren noch weitere für die Bereiche Forschung und Lehre sowie zur Erweiterung des Leistungsumfangs. Weitere Informationen dazu finden sich über die Links am Ende dieses Artikels.

Die in diesem Artikel enthaltenen Informationen wurden im Rahmen einer Linux-Evaluierung im Hochschulrechenzentrum der Uni Bielefeld erhoben.

Links

Überwachung eines Bienenbrutschranks mit Raspi-SHT21 v1.5.0

Schreibe eine Antwort

Vor ein paar Wochen erreichte mich eine Nachricht aus der Schweiz mit einer Frage zum Raspi-SHT21. Mario interessierte sich für das Projekt, um damit die Temperatur und Luftfeuchtigkeit in einem Bienenbrutschrank zu überwachen und die Messwerte für die Heizungssteuerung zu verwenden.

Neben den bereits bestehenden Funktionen wünschte sich Mario zusätzlich zur Anzeige der aktuellen Temperatur und Luftfeuchtigkeit noch die Anzeige der Minimal- und Maximal-Werte mit Zeitstempel der Messung. Da mir die Idee gefallen hat, war ich gerne bereit, ihm diese Funktionen zur Verfügung zu stellen. Die neuen Funktionen sind in die Version 1.5.0 eingeflossen, welche auf GitHub zum Download bereit steht.

Mario hat inzwischen einen ersten Prototyp fertiggestellt. Eine Beschreibung seines Projekts findet ihr auf seiner Webseite im Artikel „Brutschrank InkuPI“.

Viel Spaß beim Lesen.

Die Verwendung von „date“ in der crontab

1 Antwort

Bei der Verwendung des Kommandos date +%Y%m%dT%H%M%S in der crontab meines Benutzers erlebte ich heute eine Überraschung. Das Kommando wurde nicht wie erwartet abgearbeitet.

Das Problem ließ sich jedoch schnell und einfach lösen. Die %-Zeichen der date-Formatierungsangaben müssen mit einem Backslash escaped werden. Ein korrekter Aufruf sieht bspw. wie folgt aus:


# m h dom mon dow command
*/10 * * * * /bin/echo `/bin/date +\%Y-\%m-\%dT\%H:\%M:\%S` >> /home/bob/check.log

Erster bekannter Missbrauch eines Let’s Encrypt Zertifikats

2 Antworten

Dennis Schirrmacher berichtet in seinem heise-Artikel „Erste Malvertising-Kampagne mit Let’s-Encrypt-Zertifikat“ über die missbräuchliche Verwendung eines Let’s Encrypt Zertifikats.

Laut dem Artikel ist es Online-Gaunern gelungen, eine Subdomain für eine legitime Domain einzurichten und für diese ein Let’s Encrypt Zertifikat zu beantragen. Mit Hilfe der legitimen Domain und des vertrauenswürdigen Zertifikats wird Besuchern der Webseite Schadcode untergeschoben. Im konkreten Fall wird ein Online-Banking-Trojaner auf den Computern der Opfer installiert.

Die missbräuchliche Nutzung ist kein spezielles Problem von Let’s Encrypt. Es handelt sich vielmehr um ein generelles Designproblem der öffentlichen TLS/SSL-Infrastruktur, welches ich bereits in der Einleitung von „Certificate Pinning mit NGINX“ beschrieben habe.

Let’s Encrypt versucht den Missbrauch durch den Einsatz kurzlebiger Zertifikate einzuschränken. Dieser Versuch läuft meiner Ansicht nach jedoch weitgehend ins Leere. Denn auch Online-Gauner können die Erneuerung der ergaunerten Zertifikate mit dem Let’s Encrypt Client automatisieren.

Einen deutlich effektiveren Schutz gegen die genannte Art von Missbrauch bieten Verfahren wie „Public Key Pinning Extension for HTTP“[1. RFC 7469 – Public Key Pinning Extension for HTTP] [2. HTTP Public Key Pinning – Wikipedia (de)] und „HTTP Strict Transport Security (HSTS)“[3. RFC 6796 – HTTP Strict Transport Security (HSTS)] [4. HTTP Strict Transport Security – Wikipedia (de)]. Speziell mit Hilfe des Certificate Pinning kann ein Browser erkennen, ob ein TLS/SSL-Zertifikat zur besuchten Domain gehört oder nicht. Nähere Informationen dazu und wie das Certificate Pinning für den Webserver NGINX konfiguriert werden kann, finden sich im Artikel „Certificate Pinning mit NGINX“. Viel Spaß beim Lesen.

Pinning-Test im Firefox bei lokaler Root-CA erzwingen

1 Antwort

In Certificate Pinning mit NGINX habe ich das „Public Key Pinning for HTTP“[1. RFC 7469] und dessen Einrichtung mit dem Webserver NGINX[2. Ubuntuusers.de-Wiki-Artikel zu NGINX] beschrieben. Im vorliegenden Artikel beschreibe ich, wie man den Pinning-Test im Firefox auch bei Installation einer lokalen Root-CA aktiviert.

Schmidt schreibt in seinem Artikel[3. Schmidt, Jürgen: Festgenagelte Zertifikate: TLS wird sicherer durch Certificate Pinning, in: c’t magazin für computer technik, Nr. 23, 17.10.2015, Seite 120-121], dass Firefox in der Standardeinstellung sämtliche Pinning-Tests deaktiviert, wenn nachträglich ein Root-CA-Zertifikat auf dem System installiert wurde. Um die Pinning-Tests auch in diesem Fall zu erzwingen ist der unten genannte Parameter auf der Seite „about:config“ auf den Wert „2“ zu setzen.

security.cert_pinning.enforcement_level

Dieser Parameter kann die folgenden Werte annehmen:

  • 0 -> Schaltet die Pin-Prüfung komplett ab.
  • 1 -> Standardwert; Führt Pin-Prüfung durch, solange keine lokale Root-CA im Spiel ist.
  • 2 -> Strict; Erzwingt die Pin-Prüfung in jedem Fall.

Update vom 08.12.2015
Wie ich bei meinen Tests am vergangenen Wochenende herausgefunden habe, muss noch ein weiterer Parameter in der Firefox-Konfiguration angepasst werden, um das Public-Key-Pinning im Firefox bei Existenz eines Root CA Zertifikats zu aktivieren.

security.cert_pinning.process_headers_from_non_builtin_roots;true

Wir oben genannter Parameter auf „true“ gesetzt, führt der Firefox den Pinning Test auch durch, wenn zusätzliche Root-Zertifikate auf dem System installiert wurden.

Einen ausführlichen Bericht zum Thema findet ihr auch in „Certificate_Pinning_mit_NGINX (PDF)„.