Category: Administration / Webmaster

Categories
Administration / Webmaster German Linux QNAP Wordpress

Backup vom eigenen Server auf einem QNAP NAS zu Hause über OpenVPN am Beispiel WordPress

Der eigene Backupserver mit QNAP

Wir haben also einen Rootserver oder VServer und wollen ein Backup nach zuhause einspielen. Zuerst sollte man sich Gedanken machen, ob die Bandbreite dafür ausreicht. Ich habe eine Leitung mit 1000 MBit Downstream und 50 MBit Upstream. Das sollte auch für größere Belange voll ausreichen, da im Wesentlichen der Downstream zählt. Der zu versorgende VServer hat (leider) nur 100 MBit Downstream und ist damit also voll ausgereizt.

Nun ist zu überlegen, wie man vorgehen will, denn es gibt mehrere Möglichkeiten. Ich persönlich habe mich dafür entschieden von meinem QNAP NAS einen OpenVPN Server aufspannen zu lassen, auf den sich dann der Server verbinden kann. Den Speicher habe ich als NFSv4 freigegeben, sodass der Server hier mounten kann. Aus Sicherheitsgründen sollte man beachten, dass für diesen NAS-Zugang ein eigener Account und ein eigener Freigabeordner erstellt wird. Schließlich gibt es für Backupzwecke keinen guten Grund, warum diese Daten einfach verfügbar sein sollten.

Warnung: Ein NFSv4 sollte niemals ins Internet hinein freigegeben werden, da es bei diesem Protokoll arge Sicherheitsbedenken gibt. Schließlich ist NFSv4 für interne Netzwerke konzipiert und hält hohen Sicherheitsanforderungen nicht stand. Das Tunneln über ein VPN ist daher das Mittel der Wahl.

Bedenkt, dass ihr für folgende Schritte in der Regel eine statische IPv4-Adresse benötigt. Fragt ggf. euren Internetprovider. Bei Unitymedia/Vodafone kann man sich diese auf Anfrage z.B. einfach einrichten lassen, wenn man das Komfort-Paket hat.

OpenVPN auf QNAP einrichten

Wir installieren zuerst die App “QVPN Service” auf unserem QNAP NAS. Dieses konfigurieren wir wie auf dem folgenden Screenshot gezeigt. Wir haben hier als DNS-Server die zensurfreie und offene Variante vom Digitalcourage e.V. (IP 46.182.19.48). Man beachte außerdem, dass die Checkbox “Nutzen Sie diese Verbindung als Standard-Gateway für externe Geräte” deaktiviert ist. Dies ist erforderlich, damit der Server nicht jeglichen Traffic über das QNAP NAS leitet, was wir bei einem Server idr. nicht haben wollen. Stattdessen werden wie später auf dem Server konfigurieren, dass IP-Adressen des lokalen Netzwerks an eben dieses weitergeleitet werden. Alle anderen Einstellungen können so belassen werden. Wir laden uns noch die Konfigurationsdatei herunter (QVPN v1.1 or newer), weil diese diese später für den Server benötigen.

Nun legen wir einen neuen Freigabeordner an. Dazu gehen wir unter Systemsteuerung → Freigabeordner auf Erstellen → Freigabeordner. Wir geben dem Ordner z.B. den Ordnernamen ServerBackup. Unter Zugangsrechte hat aktuell nur der Benutzer admin Zugriff auf den Freigabeordner. Falls gewünscht, können hier noch weiteren Nutzern der Zugang gewährt werden. Wir werden gleich noch einen separaten Nutzer für unsere Backupzwecke erstellen.

Nun wäre es sinnvoll einen neuen Benutzer mit beschränkten Rechten einzurichten. Für den Fall, dass der Server kompromittiert wird, wäre es sicherlich am Besten den Schaden zu minimieren und nicht das gesamte NAS freizugeben. Ganz nach dem Motto: So wenig Rechte wie möglich, so viele Rechte wie nötig. Gehen wir also unter Benutzer auf Erstellen → Einen Benutzer erstellen. Nennen wir den Benutzer beispielsweise serverbackup und vergeben ein Passwort. Als Benutzergruppe wählen wir everyone. Unter Freigabeordnerrecht setzen wir alle Freigabeordner auf Deny und den Ordner ServerBackup auf RW, damit wir Lese- und Schreibrechte erhalten. Erstellen wir nun den Nutzer.

Sofern das noch nicht passiert ist, müssen wir in der Systemsteuerung den NFS-v4-Dienst aktivieren:

Einrichtung auf dem Server

Das OpenVPN einrichten

Wir müssen zunächst OpenVPN installieren:

sudo apt-get install openvpn

Nun konfigurieren wir das VPN. Dazu legen wir zunächst die Datei /etc/openvpn/passwords.conf an, in der wir in der ersten Zeile unseren Benutzernamen und in der zweiten Zeile unser Passwort ablegen:

serverbackup
unserPasswort123

Nun nehmen wir die zuvor als vom QNAP NAS gespeicherte Konfigurationsdatei für das VPN und legen diese als /etc/openvpn/client.conf ab. Wir müssen diese noch so anpassen, dass Benutzername und Passwort aus unserer Datei ausgelesen werden. Ursprünglich ist es so vorgesehen, dass beim Herstellen der VPN-Verbindung per Prompt nach Benutzername und Passwort gefragt werden. Da wir eine automatisierte Lösung benötigen, müssen wir den Benutzernamen und das Passwort natürlich hinterlegen. Das haben wir bereits getan. Also modifizieren wir die client.conf an der Stelle auth-user-pass wie folgt:

auth-user-pass /etc/openvpn/passwords.conf

Die Datei client.conf sollte nun in etwa wie folgt aussehen:

client
dev tun
script-security 3
remote 42.42.42.42 1194
resolv-retry infinite
nobind
auth-nocache
auth-user-pass /etc/openvpn/passwords.conf
remote-cert-tls server
reneg-sec 0
cipher AES-256-CBC
tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-256-$
float
proto udp
explicit-exit-notify 1
<ca>
...
</ca>

Eine sinnvolle Methode die VPN Verbindung herzustellen, wäre natürlich beim Systemstart. Daher legen wir nun die Datei /etc/init.d/iproute.sh
für den init-Prozess an:

!/bin/sh
service openvpn@client start
sleep 30s
ip route add 192.168.178/24 dev tun0
sleep 5s
mount -a

Hier wird erst die VPN-Verbindung hergestellt. Zur Sicherheit warten wir 30 Sekunden. Die interne IP-Adresse meines NAS lautet 192.168.178.46. Daher legen wir das Netz 192.168.178.* auf das VPN um, also auf tun0. Wir warten noch mal 5 Sekunden. Dann mounten wir alle Laufwerke, was insbesondere unser NFSv4 einschließt. Den entsprechenden Eintrag für die fstab besprechen wir gleich.

Wir müssen das Skript noch für den Systemstart verlinken. Dies ist für Runlevel 3 (Multi-User Mode mit Netzwerk) und Runlevel 5 (mit GUI) erforderlich, auch wenn für Server im Regelfall Runlevel 3 reichen würde:

ln -s ../init.d/iproute.d /etc/rc3.d/S07iproute.sh
ln -s ../init.d/iproute.d /etc/rc5.d/S07iproute.sh

Leider ist es aus meiner persönlichen Erfahrung so, dass die VPN-Verbindung auch mal abbrechen kann und dann nicht wieder erneut aufgebaut wird. Ich habe mich deshalb dafür entschlossen, das Skript zusätzlich per Cronjob auszuführen und zwar jeweils wenige Minuten bevor das Backup erfolgen soll. Wenn wir das Backup z.B. um kurz nach 3:00 Uhr ausführen möchten, können wir die Cronjobdatei /etc/cron.d/openvpn z.B. wie folgt definieren:

0 3 * * * root /etc/init.d/iproute.sh

NFSv4 Filesystem mounten

Um die nötigen Voraussetzungen zu schaffen, müssen wir zuerst nfs-common installieren:

sudo apt-get install nfs-common

Nun konfigurieren wir /etc/fstab:

192.168.178.46:/ServerBackup /mnt/RemoteServerBackup nfs rw 0 0

Hierbei ist 192.168.178.46 die lokale IP unseres NAS und ServerBackup der Name unseres Freigabeordners, den wir für das Backup konfiguriert haben. Wir mounten das Ganze nach /mnt/RemoveServerBackup und zwar als nfs-Dateisystem mit Lese- und Schreibrechten (rw).

Nicht vergessen, den Mountpoint auch zu erstellen:

mkdir /mnt/RemoteServerBackup

WordPress Backup einrichten

Wir installieren das Plugin BackWPup und erstellen einen neuen Auftrag. Hier wählen wir unter Allgemein “Backup in Verzeichnis” und unter Planen stellen wir z.B. täglich um 3:25 Uhr ein. Unter “Ziel: Verzeichnis” habe ich für meinen Blog z.B. /mnt/RemoteServerBackup/the_digital_native/wordpress/ eingestellt. Da ich noch weitere Backups auf diese Weise erstelle, macht es Sinn einen entsprechenden Unterordner zu wählen.

Konfiguration und Backup testen

Um das Ganze zu testen, stellen wir auf dem Server erst mal testweise die VPN-Verbindung her und mounten das Dateisystem:

service openvpn@client start
ip route add 192.168.178/24 dev tun0
mount -a

Wir gehen nun unter BackWPup in die Liste der Aufträge und wählen für den eben neu erstellten Auftrag Jetzt starten aus. Der Auftrag sollte nun durchlaufen. Nach Abschluss des Auftrags prüfe einfach, ob das entsprechende Backup auf deinem NAS liegt.

So, wir sind fertig! Wir können nun über VPN automatisiert ein WordPress Backup auf unserem QNAP NAS erstellen.

Categories
Administration / Webmaster Datenschutz English Linux OccuSearch SearX

Daemonize and control SearX with the service command

SearX
SearX Logo

Under several Linux distributions, including Debian and Ubuntu, we have the service command to controll daemons, e.g. service apache2 restart. In this article, we learn how to create a service-command for the standalone version of the SearX meta search engine. We build upon the default installation as prescribed within the quick start guide of the project documentation. We include both, searX and filtron.

Introduction

First we need a possibility to start SearX as a daemon, so we install the daemonize command:

sudo apt-get install daemonize

With daemonize, we can have an error-log, a std-out log and some pid that takes care about having only one instance running. With SearX installed at the default destination /opt/searx, we can execute the following command to start a SearX daemon:

daemonize -a -e /var/log/searx.error.log -o /var/log/searx.log -p /var/run/searx.pid -l /var/lock/subsys/searx /opt/searx/searx-ve/bin/python /opt/searx/searx/webapp.py

In a similar way, we can start a filtron instance (assuming the filter rules at /etc/filtron/rules.json):

daemonize -a -e /var/log/filtron.error.log -o /var/log/filtron.log -p /var/run/filtron.pid -l /var/lock/subsys/filtron /root/go/bin/filtron -rules /etc/filtron/rules.json

Usually, we will start filtron first and then start SearX.

We furthermore need some kill commands to stop filtron and SearX. We use ps, grep, awk and kill.

Stopping filtron:

kill $(ps -aux | grep filtron | awk '{print $2}')

Stopping SearX:

kill $(ps -aux | grep /opt/searx/searx/webapp.py | awk '{print $2}')

Realizing the service commands

We usually have three options following the service command: service searx start, service searx stop and service searx restart. This results in the following code snippet for the searx.sh file stored at /etc/init.d/searx.sh:

#! /bin/sh
sleep 3
case "$1" in
  start)
        daemonize -a -e /var/log/filtron.error.log -o /var/log/filtron.log -p /var/run/filtron.pid -l /var/lock/subsys/filtron /root/go/bin/filtron -rules /etc/filtron/rules.json
        daemonize -a -e /var/log/searx.error.log -o /var/log/searx.log -p /var/run/searx.pid -l /var/lock/subsys/searx /opt/searx/searx-ve/bin/python /opt/searx/searx/webapp.py
        ;;
   stop)
        kill $(ps -aux | grep filtron | awk '{print $2}')
        kill $(ps -aux | grep /opt/searx/searx/webapp.py | awk '{print $2}')
        ;;
  restart)
        kill $(ps -aux | grep filtron | awk '{print $2}')
        kill $(ps -aux | grep /opt/searx/searx/webapp.py | awk '{print $2}')
        daemonize -a -e /var/log/filtron.error.log -o /var/log/filtron.log -p /var/run/filtron.pid -l /var/lock/subsys/filtron /root/go/bin/filtron -rules /etc/filtron/rules.json
        daemonize -a -e /var/log/searx.error.log -o /var/log/searx.log -p /var/run/searx.pid -l /var/lock/subsys/searx /opt/searx/searx-ve/bin/python /opt/searx/searx/webapp.py
        ;;
        *)
        ;;
esac
exit 0

In some cases we have issues with uswgi. Therefore, consider to uninstall uswgi.

sudo apt-get remove uswgi

Now, reinitialize the service command with the following command:

systemctl daemon-reload

Now it is possible to controll filtron and SearX in a comfortable way. Try the following:

service searx start
service searx stop
service seary restart

You will see SearX and filtron starting, stopping or restarting.

Final Remarks

Have some fun with this comfortable solution!

Do it! Build your own search engine! Go go go!

For an example instance, have a look at https://occusearch.net. Feel free to use and recommend this instance to your family, friends and colleagues.

Categories
Datenschutz German Mailserver OccuMail

Ein Spamfreies Postfach mit OccuMail ZeroSpam

Heute soll es um unseren Maildienst OccuMail gehen, für den auch du eine kostenlose Adresse bekommen kannst. Typischerweise vergeben wir etwa 1GB Speicher kostenlos. Mehr Speicher können wir gerne zur Verfügung stellen, aber wir bitten dann um eine geringfügige Beteiligung an den Serverkosten. Für mehr Informationen, bitte anfragen!

Mögliche, kostenlose Mailaliase sind:

  • nickname@occumail.net
  • nickname@new-visual-dimension.de
  • nickname@the-digital-native.de
  • nickname@the-digital-native.net
  • nickname@your-domain.tld (zum Selbstkostenpreis)

Unser Dienst ist Datenschutzfreundlich, Werbefrei und deine Mailinhalte werden von uns nicht eingesehen oder kontrolliert. Außerdem geben wir deine Mailinhalte niemals an Behörden oder sonstige staatliche Institutionen heraus. Im Zweifelsfall würden wir es auf einen Gerichtsprozess ankommen lassen. Glücklicherweise gab es eine solche Anfrage bis heute noch nie.

Bei OccuMail gibt es keinen Spamfilter

Einige Nutzer von OccuMail fragten mich bereits, warum es denn keinen Spam-Ordner in Ihrem Postfach geben würde. Die Antwort ist einfach: Wir bieten keinen Spamfilter an. Warum das so ist? Weil man seine E-Mailadresse Spamfrei halten kann. Ich habe meine aktuelle E-Mailadresse seit Oktober 2013, also knapp 7 Jahre, und erhalte immernoch keinerlei Spam.

Dafür muss man jedoch ein paar Regeln einhalten:

  • Poste deine E-Mailadresse niemals öffentlich im Internet auf irgendeiner Website.
  • Wenn du deine E-Mailadresse doch irgendwo publizieren musst (z.B. Impressum), dann nimm dafür, wenn möglich, einen Alias, der auf deine E-Mailadresse weiterleitet. Du kannst diesen Alias dann im Notfall einfach deaktivieren, ohne deine Hauptadresse zu verlieren.
  • Wenn du deine E-Mailadresse publizierst, tue dies niemals im Klartext, sondern als Privacy Captcha. Als Bild, oder besser als Privacy Captcha, kann deine E-Mailadresse nicht durch Bots gefunden und für Spam missbraucht werden. Solche Bots durchsuchen tagtäglich so gut wie alle Webseiten und schnüffeln E-Mailadressen auf!
  • Wann immer du dich bei irgendeinem Service oder Dienstleister mit einer E-Mailadresse registrierst, tue dies mit OccuMail ZeroSpam.

Über OccuMail ZeroSpam

Die Idee ist, wann immer du dich irgendwo mit einer E-Mailadresse registrierst, eine neue Mailadresse zu benutzen. Diese E-Mailadresse ist dann ausschließlich für diesen einen Anbieter bestimmt. Der Hintergrund: Meist wird deine E-Mailadresse nicht durch Freunde und Bekannte an Spammer und Phisher gegeben, sondern durch irgendeinen Serviceanbieter oder Dienstleister.

Wie funktioniert das bei OccuMail ZeroSpam?

Wenn du bei uns eine Adresse nickname@occumail.net hast, kannst du selbst über unsere Administrationsoberfläche Postfix Admin E-Mailadressen der Form alias@nickname.occumail.net anlegen. Wenn du deine eigene Top-Level Domain hast, dann natürlich auch alias@your-domain.tld. Wir empfehlen, sprechende Namen zu verwenden.

Erstelle dir z.B. eine der folgenden E-Mailadressen:

  • amazon@nickname.occumail.net
  • buch7@nickname.occumail.net
  • facebook@nickname.occumail.net
  • diaspora@nickname.occumail.net
  • twitter@nickname.occumail.net
  • mastodon@nickname.occumail.net

Das sieht in unserer Administrationsoberfläche wie folgt aus:

Wenn du Spam erhältst, kannst du einen Mailalias nun jederzeit wieder löschen. Wir empfehlen jedoch den Eintrag einfach zu deaktivieren. Dann kommen auch keine Mails mehr an, aber du hast den Überblick von wo schon mal Spam- oder Phishingmails kamen.

Tritt den Übeltätern auf die Füße!

Eine weitere tolle Eigenschaft dieser Methode: Erhältst du Mails auf eine Adresse, weißt du ja wo du diese Adresse benutzt hast. Von daher hast du die Möglichkeit dem Verantwortlichen auf die Füße zu treten. Entweder dieser hat die Daten selbst an Spammer oder Phisher weitergegeben, oder es gab ein Sicherheitsleck, über das die Kundendaten entwendet wurden. Auch letzteres gilt es zu Verfolgen, da die Kunden darüber informiert werden müssen. Das gilt sogar qua Gesetz!

Der Fall Foto Erhardt

Tatsächlich hatte ich schon mal einen solchen Fall, wo bei mir persönlich ein Phishingversuch auf meinen PayPal Account stattgefunden hat und das sogar unter Angabe meines Namens und meiner kompletten Adresse. Dank OccuMail ZeroSpam konnte ich den Ursprung des Ganzen nachverfolgen. An dieser Stelle nehme ich auch kein Blatt vor den Mund und sage, dass dieser Fall Foto Erhardt betraf, wo ich einige Zeit zuvor eine Onlinebestellung getätigt hatte. Ich ging zunächst von keiner böswilligen Absicht aus und unterstellte ein Sicherheitsleck, also dass die Daten gestohlen wurden. Ich informierte Foto Erhardt sofort telefonisch, wo man sich wenig zu interessieren schien und man mir sagte, ich sollte doch eine E-Mail schreiben. Das tat ich auch. Diese blieb jedoch unbeantwortet. Es gab auch keine Information der Kunden über ein Datenleck, sodass Foto Erhardt seinen gesetzlichen Pflichten nicht nachgekommen ist. Ich entschied mich deswegen damals, zumindest den Fall publik zu machen. Ich postete den Vorfall in einigen Foren für Fotografie. Angesichts dieses Verhaltens, sollte man doch noch mal überdenken, ob man denn gerade bei diesem Anbieter bestellen möchte (sei es auch gerade der günstigste).

Fazit

Mit ein paar grundlegenden Regeln und OccuMail ZeroSpam kann man den Spammern und Phishern ein Schnippchen schlagen. Möglich wird dies durch das Prinzip “eine Adresse pro Dienst”. Als Zusatznutzen kann man die Schuldigen identifizieren. Ich selbst habe übrigens inzwischen etwa 370 Aliase, wovon 40 deaktiviert sind. Das Prinzip hat mein Postfach also wirkungsvoll geschützt.

Wer noch keinen Adresse von OccuMail hat, der darf sich nun gerne melden und in den Genuss von OccuMail ZeroSpam kommen. Wer schon einen Account hat und ZeroSpam noch nicht nutzt, der möge sich zwecks Einrichtung kurz bei mir melden. Ich wünsche ein Spamfreies Wochenende!

Categories
Administration / Webmaster German Linux Mailserver

Serverseitige Mailfilter mittels Sieve. Einrichtung von Dovecot & Roundcube

Sieve-Skripte sind eine einfache Möglichkeit Mailfilter auf Mailservern umzusetzen. So können serverseitig etwa Regeln definiert werden, die eingehende Nachrichten z.B. bei vorliegen eines bestimmten Absenders, Empfängers oder Betreffs in einen Ordner verschiebt. Nachrichten können z.B. auch gelöscht oder als gelesen markiert werden. Man kann auch Nachrichten weiterleiten oder mit automatisierter Antwort ablehnen. Auch Abwesenheitsnotizen sind ein Typischer Anwendungsfall.

Die Möglichkeiten sind im Prinzip sehr ähnlich zu den Filterregeln, die man in Thunderbird hinterlegen kann. Der Wesentliche Vorteil: Das Filtern erfolgt auf dem Server. Das ist insbesondere dann von Vorteil, wenn man von mehreren Clients auf ein IMAP-Account zugreift. Da wir heutzutage in der Ära der Smartphones angelangt sind, tut das quasi jeder. Manch einer neben Desktop und Smartphone womöglich noch auf der Arbeit oder per Webmail. Mittels Sieve muss man die Filter nur ein mal pflegen und zwar auf dem Server.

Sieve Clients

Sieve stellt ein eigenes Protokoll zur Verfügung und ist unter Port 4190 zu erreichen. Nun könnte man seine Filter tatsächlich sogar per Telnet pflegen. Komfortabler ist aber ein Sieve Client (Überblick hier). Viele Clients sind jedoch veraltet. Empfehlenswert ist Manage Sieve (Windows und Linux), welches das editieren von Sieve Skripten mit Syntax-Hervorhebung ermöglicht. Das ist toll für Informatiker und Enthusiasten, wird aber den Otto-Normal-Verbraucher abschrecken. Wer seinen Nutzern die Filter komfortabel per GUI erstellen lassen möchte, dem sei die Sieve Erweiterung für den Webmailclient Roundcube empfohlen. Weiterer Vorteil: Man braucht keine weitere Software installieren. Wir besprechen daher im Folgenden auch die Installation von Sieve in Roundcube.

Editieren eines Sieve Skripts mittels Manage Sieve unter Linux

Voraussetzungen

Wir verwenden folgendes System:

  • Debian 10 (Buster)
  • dovecot 2.3.4.1 (Befehl /usr/sbin/dovecot --version)

Wir gehen davon aus, dass Dovecot bereits vollständig für die Verwendung mit IMAP eingerichtet ist. Auch Roundcube sollte schon installiert sein. Wir besprechen hier nur die nötige Konfiguration für Sieve!

Dovecot einrichten

Bekanntermaßen wird Sieve häufig auch für das Filtern von z.B. Spam in den Spam-Ordner verwendet. Während hier die Regeln lediglich durch den Administrator auf dem Server abgelegt werden, möchten wir dem Endanwender ermöglichen Sieve-Skripte anzuwenden. Hierzu verwenden wir neben dem sieve Plugin auch managesieve.

Zuerst installieren wir die Sieve-Erweiterung von Dovecot:

sudo apt-get install dovecot-sieve dovecot-managesieved

Sieve für LMTP aktivieren

Wir aktivieren nun das Sieve Plugin für den LMTP (Local Mail Transfer Protocol). Dazu editieren wir die Datei /etc/dovecot/conf.d/20-lmtp.conf:

protocol lmtp {
  # Space separated list of plugins to load (default is global mail_plugins).
  mail_plugins = $mail_plugins sieve
}

Sieve konfigurieren

Nun richten wir Sieve selbst ein. Dazu editieren wir /etc/dovecot/conf.d/90-sieve.conf. Generell gilt, dass ein Benutzer beliebig viele Sieve-Skripte haben kann. Diese müssen an einem Ort gespeichert werden. Hierfür bietet sich z.B. /var/vmail/sieve/scripts/%u an. Hierbei ist %u ein Platzhalter für den vollständigen Benutzernamen inklusive Domain, also der Form user@example.com. Außerdem muss der Ort für das aktuell aktive Sieve-Skript eines Nutzers angegeben werden. Ein Nutzer kann zwar beliebig viele Sieve-Skripte definieren, hat aber immer nur genau ein aktives Skript. Wir nehmen hier den Pfad /var/vmail/sieve/%u.sieve. Die 90-sieve.conf beinhaltet nun folgendes:

sieve = file:/var/vmail/sieve/scripts/%u;active=/var/vmail/sieve/%u.sieve

Wer ein Sieve-Skript für einen Spamfilter anlegen möchte, also z.B. bei vorliegen eines Spam-Headers in einen Spam-Ordner filtern möchte, tut dies in der Regel bevor das Skript des Benutzers ausgeführt wird. Daher wird sieve_before gesetzt. Folgendes könnte in 90-sieve.conf eingetragen werden:

sieve_before = /var/vmail/sieve/spam-global.sieve

Die Datei spam-global.sieve kann wie folgt aussehen:

require "fileinto";
if header :contains "X-Spam-Flag" "YES" {
  fileinto "Spam";
}

Managesieve konfigurieren

Um unsere Sieve-Skripte auch von außen bearbeiten zu können, müssen wir nun managesieve aktivieren. Wir bearbeiten /etc/dovecot/conf.d/20-managesieve.conf:

service managesieve-login {
  inet_listener sieve {
    port = 4190
   }
}

Damit hätten wir es geschafft. Jetzt noch neu starten!

sudo service dovecot restart

Roundcube

Zuerst richten wir das Plugin managesieve für Roundcube ein. Dazu legen wir die Configdatei config.inc.php durch Kopieren der Defaultconfig config.inc.php.dist an:

cp /path-to-roundcube/plugins/managesieve/config.inc.php.dist /path-to-roundcube/plugins/managesieve/config.inc.php

Nun editieren wir die config.inc.php wie folgt:

$config['managesieve_port'] = 4190;
$config['managesieve_host'] = '%h';
$config['managesieve_usetls'] = true;

Der Port 4190 ist der Standardport für Sieve und wir haben diesen in der managesieve.conf von Dovecot entsprechend gesetzt. Ich gehe davon aus, dass die Hostnamen in der Roundcube Konfigurationsdatei explizit gesetzt sind. So ist es mit dieser Konfiguration auch möglich Sieve-Skripte auf fremden Mailservern (ungleich localhost) zu editieren. Da dies möglich ist, sollten wir managesieve_usetls auf jeden Fall auf true setzen, damit wir Transportverschlüsselung haben. Wir müssen nun noch das managesieve-Plugin in der Roudcube Konfigurationsdatei aktivieren. Bei mir sieht /path-to-roundcube/config/config.inc.php ausschnittsweise wie folgt aus:

$config['default_host'] = array('tls://imap.occumail.net','tls://imap.digitalcourage.de');
$config['smtp_server'] = 'tls://smtp.%z';
$config['smtp_port'] = '587';
$config['plugins'] = array(
'emoticons',
'archive',
'zipdownload',
'password',
'managesieve',
);

Filter in Roundcube bearbeiten

Wir können uns nun in Roundcube einloggen. Oben rechts unter Einstellungen finden wir nun links den Eintrag Filter. Hier können wir neue Filtersätze anlegen und einen Filtersatz aktivieren. Filter können sehr komfortabel über die GUI zusammengeklickt werden. Roundcube generiert das Sieve-Skript und pusht dieses auf den Server.

Bezüglich der möglichen Filter sind bei mir keine Wünsche offen geblieben. Aktuell wäre mir nicht bekannt, dass die Sieve-Skriptsprache Operationen unterstützt, die hier nicht abgedeckt werden. Solltest du andere Erfahrungen gemacht haben, dann kontaktiere mich doch bitte und ich werde den Artikel entsprechend ergänzen!

Einstellen eines Sieve-Filters auf Roundcube
Categories
Administration / Webmaster Datenschutz German IT-Security Linux Wordpress

Sicherheit und Datenschutz mit Content-Security-Policy Header für WordPress

Heute wollen wir uns mit Content Security Policy (CSP) Headern beschäftigen. In erster Linie ist dies ein Sicherheitsfeature, um das Laden von (Java-)Skripten, aber auch Bilder, Fonts, iFrames etc. aus böswilligen Quellen zu unterbinden und so insbesondere Cross-Site-Scripting zu unterbinden. Wikipedia sagt dazu folgendes:

Content Security Policy (CSP) ist ein Sicherheitskonzept, um Cross-Site-Scripting und andere Angriffe durch Einschleusen von Daten in Webseiten zu verhindern.

In der Praxis sind jedoch Cross-Site-Scripting-Schwachstellen sehr verbreitet. Die Content Security Policy erzwingt eine strikte Trennung zwischen Inhaltsdaten im HTML-Code und externen Dateien z.B. mit JavaScript-Code. In der Regel ist der JavaScript-Code statisch und wird nicht dynamisch generiert.

Content Security Policy, Wikipedia

Wir wollen CSP aber für noch mehr benutzen: Wir können damit auch unerwünschte Drittanbieter ausschließen, die uns WordPress quasi aufzwingt. Diese Drittanbieter können die Besucher eurer Webseite möglicherweise (in einigen Fällen sogar ziemlich sicher) tracken. Wer seinen Benutzern gegenüber Datenschutzfreundlich sein möchte, verzichtet nicht nur auf Google Analytics, sondern auch auf andere Drittanbieter. Dennoch möchte ich das Analysieren von Benutzerverhalten nicht gänzlich verteufeln, denn es liefert nützliche Einsichten, welche Reichweite man mit seinem Angebot erzielt und welche Angebote die Besucher womöglich besonders interessieren. Aber dazu gibt es auch Datenschutzfreundliche Alternativen: Matomo ist ein Paradebeispiel, welche ein selbst gehostetes System darstellt und freingranulare Einstellungen im Bezug auf Datenschutz bietet. Aus meiner Sicht ist der wichtigste Punkt, dass die Daten in den eigenen Händen bleiben und nicht z.B. bei Google landen. Ich beschreibe daher hier auch wie Matomo mit CSP funktioniert, wenn dieses auf einer Subdomain wie https://matomo.the-digital-native.de betrieben wird.

Für WordPress ganz übliche Drittanbeiter sind:

  • Gravatar: Verknüpft beim Dienstanbieter hinterlegte Avatare mit der E-Mailadresse. Sammelt möglicherweise Daten und wird ohnehin von nur wenigen Nutzern gebraucht. Damit Benutzer trotzdem Avatare verwenden können, ist es ratsam das Plugin WP User Avatar als Ersatz zu installieren.
  • Google Fonts: Stellt zentral und kostenlos Schriftarten zur Verfügung, die durch Webdesigner einfach als Fremdresource eingebunden werden können. Eine der ärgerlichsten Datenschutzsünden, denn Google erfährt so von jedem Besucher! Außerdem ist es wirklich sehr einfach möglich, Fonts auch auf dem eigenen Server abzulegen und per CSS nachzuladen. Es gibt also nicht mal einen guten Grund auf diesen Service zurück zu greifen.

Basiskonfiguration für WordPress

Folgende Konfiguration habe ich ausführlich getestet und kann im VirtualHost von apache2 so in der Form hinterlegt werden:

Header always set Content-Security-Policy \
  "default-src 'none'; \
  img-src 'self' data: \
  style-src 'self' 'unsafe-inline'; \
  font-src 'self' data:; \
  script-src 'self' 'unsafe-inline' 'unsafe-eval'; \
  frame-src 'self' \
  form-action 'self'; \
  base-uri 'none'; \
  frame-ancestors 'self'"

Was bedeuten diese Optionen nun?

  • default-src wird immer dann angewandt, wenn eine Ressource geladen werden soll, auf die keine andere Regel zutrifft. Es wird hier empfohlen none zu setzen. Wer ein Kontakt-Formular wie Contact Form 7 einsetzt, wird hier leider zumindest self setzen müssen. Theoretisch sollte das auch anders gehen (via Direktive connect-src auf self). Leider funktioniert dies in der Praxis nicht.
  • img-src definiert, woher Bilder per <img>-Tag geladen werden können. self benötigt man hier logischerweise. Die Option data: ermöglicht das Laden von Bildern aus im HTML codierten Bildmaterial. Dies nutzt WordPress ebenfalls. Wer weitere Quellen für Bilder hat, muss diese hier angeben. Hier schließen wir u.a. Gravatar aus. Wer seinen Benutzern trotz allem Gravatar zur Verfügung stellen möchte, muss hier die URL https://secure.gravatar.com hinzufügen.
  • style-css gibt an, woher CSS-Dateien geladen werden können. Leider muss hier die unsichere Option unsafe-inline hinzugefügt werden, weil WordPress mittels <style>-Tag CSS-Attribute in das HTML einbettet. Dies ist ein Sicherheitsdefizit von WordPress. Wir schließen hier insbesondere auch Google Fonts aus, denn darauf kann man bei auch nur etwas Liebe zum Datenschutz wirklich verzichten.
  • font-src gibt Möglichkeiten zum Nachladen von Schriftarten an. Werden nur Systemschriftarten eingesetzt, kann hier none gewählt werden. WordPress lädt aber, je nach Theme, Schriftarten nach. Zum Teil auch eingebettete Schriftarten, sodass data: nötig wird.
  • script-src gibt insbesondere die Quellen für JavaScripte an. Dass wir hier self haben ist ok, jedoch erfordert WordPress auch unsafe-inline und unsafe-eval, was ein besonderes Sicherheitsrisiko darstellt. Letzteres ermöglicht das Ausführen von JavaScript-Code mit der so genannten eval()-Funktion und gibt als typischer Punkt, um Schadcode einzuschleusen. Die Entwickler von WordPress sollten hier dringend nachbessern und auch ohne unsafe-eval auskommen.
  • frame-src ermöglicht das Laden von Webseiten in <frame> oder <iframe> Elementen. Sollte aus Sicherheitsgründen auf self beschränkt bleiben, falls möglich.
  • form-action beschränkt die Webseiten, die durch das Absenden eines Formulars erreicht werden können. Für Funktionen wie Kontaktformulare, Newsletteranmeldung (lokal) etc. sollte hier self genügen.
  • Setzt man base-uri auf none, muss jede verlinkte Ressource mit einem vollständigen Pfad angegeben werden. Damit wäre z.B. <img src="my_picture.png"> nicht zulässig, sehr wohl aber <img src="https://the-digital-native.de/my_picture.png">. Erfreulicherweise setzt Wodpress dieses Sicherheitsfeature um!
  • frame-ancestors erlaubt bzw. verbietet, dass die eigene Webseite in andere Webseiten eingebunden werden kann, z.B. per iframe. Die Option self verhindert möglicherweise Missbrauch des eigenen Contents durch andere Webseitenbetreiber.

Konfiguration von Matomo

Ich empfehle Matomo auf der eigenen Domain zu hosten, z.B. als Subdomain. In dem Fall muss Matomo in img-src sowie script-src hinzugefügt werden. Wenn man die Opt-Out-Box von Matomo z.B. in die Datenschutzerklärung einbinden möchte, muss Matomo auch als frame-src zulassen, da es mittels iFrame eingebunden wird.

Header always set Content-Security-Policy \
  "default-src 'none'; \
  img-src 'self' data:  https://matomo.the-digital-native.de; \
  style-src 'self' 'unsafe-inline'; \
  font-src 'self' data:; \
  script-src 'self' https://matomo.the-digital-native.de 'unsafe-inline' 'unsafe-eval'; \
  frame-src 'self' https://matomo.the-digital-native.de; \
  form-action 'self'; \
  base-uri 'none'; \
  frame-ancestors 'self'"

Konfiguration für WordPress Administration

Die WordPress-Administration benötigt etwas mehr Rechte, um korrekt zu funktionieren. Da ich die Rechte für die Benutzerspezifischen Seiten nicht unnötig ausweiten möchte, habe ich in apache2 eine Location-Direktive erstellt, die auf das Unterverzeichnis wp-admin abzielt.

<Location ~ "/wp-admin">
Header always set Content-Security-Policy \
  "default-src 'self'; \
  img-src 'self' data: https://ps.w.org https://s.w.org; \
  style-src 'self' 'unsafe-inline'; \
  font-src 'self' data:; \
  script-src 'self' 'unsafe-inline' 'unsafe-eval'; \
  form-action 'self'; \
  base-uri 'none'; \
  frame-ancestors 'self'"
</Location>

Konfiguration von Matomo

Auch hier braucht eine Matomo Instanz ein paar extra-Regeln, um die Einbettung in das Adminmenü zu ermöglichen. Eine Konfiguration kann wie folgt aussehen:

<Location ~ "/wp-admin">
Header always set Content-Security-Policy \
  "default-src 'self'  https://matomo.the-digital-native.de; \
  img-src 'self' data: https://ps.w.org https://s.w.org  https://matomo.the-digital-native.de; \
  style-src 'self' 'unsafe-inline'; \
  font-src 'self' data:; \
  script-src 'self' https://matomo.the-digital-native.de 'unsafe-inline' 'unsafe-eval'; \
  form-action 'self'; \
  base-uri 'none'; \
  frame-ancestors 'self'"
</Location>

Weitere Plugins

Wer das Plugin Yoast zur SEO-Optimierung benutzt, muss unter default-src den Eintrag https://yoast.com hinzufügen.

Generell gilt, dass ihr bei weiteren Plugins immer überprüfen solltet, ob diese auch funktionieren. Unter F12 gibt es in Firefox & Chrome die Console, wo durch CSP geblockte Inhalte angezeigt werden. Surft damit durch eure Webseite und auch das Admin-Menü. Fügt, falls nötig, weitere Webseiten zu den einzelnen Policies hinzu. Bedenkt aber: Lokale Lösungen sind Drittanbietern aus Datenschutzsicht immer vorzuziehen! Verwendet z.B. einen eigenen Captcha-Generator statt Googles ReCaptcha. Ja, es gibt viele Dienste, die euren Benutzern tolle Funktionalitäten bieten, aber wägt immer zwischen Datenschutz und Nice-To-Have Features ab!

Qualität der CSPs testen

Dafür gibt es das Mozilla Obversatory. Trotz dass wir das Maximum rausgeholt haben und einige grüne Häkchen sammeln, bekommen wir aktuell leider -20 Punkte. Kaputt macht uns das Ranking unsafe-inline und unsafe-eval. Hier sind die Softwareentwickler von WordPress gefragt, die hier als einziges Abhilfe schaffen können. Es bleibt Verbesserungspotential!

Mozilla Obversatory für https://the-digital-native.de

Garvatar Ersetzen

Fazit

Mit Content Security Policy Headern kann man eine Menge an zusätzlicher Sicherheit und Datenschutz für seine Nutzer erzielen. Eine gut getestete Grundlage für eine WordPress-Basisinstallation sowie eine Matomo Instanz haben wir hier geliefert. Bereits dies war tagelange Ausprobiererei, bis wir das Optimum an CSPs erreicht haben, ohne das die Funktionalität Schaden genommen hat. Komplexere Installationen benötigen hier evtl. nochmals mehr Aufwand.

Categories
Cloud Datenschutz German IT-Security

Datenschutzfreundliche Cloudspeicherdienste im Vergleichstest

Aktueller Stand: 28. Mai 2020

Warum brauchen wir alternative Cloudspeicherdienste?

Ob Dropbox, Google Drive, Microsoft OneDrive oder die iCloud, all diese Dienste sind nicht für ihre guten Datenschutzbestimmungen bekannt und bieten keine Ende-zu-Ende-Verschlüsselung. Wir zeigen, warum das ein Problem ist und dass es sehr wohl Alternativen gibt: Vertrauenswürdige Anbieter und Clouds, die auf dem eigenen Webserver betrieben werden – selbst gehostet also. Diese Alternativen sind nicht immer kostenlos im monetärem Sinne, aber bedenke: Du zahlst immer etwas – entweder mit Geld oder halt mit deinen Daten. Überlege selbst, was dir besser erscheint!

Kriterien für einen guten Cloudspeicher

Ende-zu-Ende-Verschlüsselung: Ein wichtiges Kriterium ist die Ende-zu-Ende-Verschlüsselung. Das bedeutet, dass Dateien direkt auf dem Rechner bzw. Smartphone verschlüsselt werden und erst danach zum Server transportiert werden. Der Vorteil: Sogar die Person, die verwendeten Server betreibt, kann Ihre Daten nicht sehen. Das sogenannte „Zero-Kowledge-Prinzip“: Ihr Schlüssel wird nicht beim Anbieter hinterlegt und nur Sie haben Zugriff auf Ihre Daten. Das schließt natürlich auch Geheimdienste und Sicherheitsbehören aus und sichert die Daten vor Diebstahl bei einem Einbruch in den Cloud-Server. Wichtig: Vergessen Sie niemals Ihr Passwort, denn auch der Serverbetreiber kann dieses nicht zurücksetzen und Ihre Daten wären nach einem Passwort-Verlust endgültig verloren.

Zwei-Faktor-Authentifizierung: Als zusätzliches Sicherheitskriterium gilt die Zwei-Faktor-Authentifizierung. Davon spricht man, wenn neben Ihrem Passwort eine weitere Komponente zum Einloggen benötigt wird. Eine gängige Methode ist die Nutzung eines mobilen Authentikators, d.h. einer App, die ein einmal zu verwendendes Passwort erzeugt. Wir empfehlen auch hier, nicht auf Google zu setzen, sondern die Open-Source-Apps Aegis bzw. andOTP für Android oder Authenticator von Matt Rubin für iOS. Möglich ist aber auch eine Authentifizierierung per SMS (mTAN). Wichtig: Wenn Sie sich über Ihr Smartphone in die Cloud einloggen und das Einmalpasswort auch auf dem Smartphone generieren, handelt es sich streng genommen nicht mehr um eine Zwei-Faktor-Authentifizierung. Denn dann nutzen Sie das gleiche Endgerät für beide Faktoren.

Open Source Software: Auch wenn Sie sich dafür entscheiden keinen eigenen Server zu betreiben und einem Anbieter zu vertrauen, ist ein wichtiges Kriterium, ob die verwendete Software Open Source ist. D.h. der Programmcode ist einsehbar. Dies ermöglicht es Dritten, die Versprechen von Anbietern zu prüfen: Funktioniert die Verschlüsselung wirklich wie versprochen? Ist die Anwendung sicher?

Örtlichkeit: Einige der genanten Dienste sind US-Firmen und hosten auch dort. Gemäß PATRIOT Act  müssen Ihre Daten, wenn sie abgegriffen werden den US-Behörden zur Verfügung gestellt werden. Durch den  CLOUD Act gilt dies auch für US-Firmen, die im Ausland hosten. Unter Umständen müssen US Anbieter sogar Backdoors, also Hintertüren einbauen, die die Verschlüsselung unterwandern. Der CLOUD Act verpflichtet Unternehmen sogar zum Schweigen darüber. Diese Hintertüren machen die Software natürlich unsicherer, denn sie können auch von Dritten ausgenutzt werden. Nutzen Sie Cloud-Dienste-Anbieter aus Deutschland, anderen EU-Ländern oder der Schweiz. Sie sind weder vom PATRIOT noch dem CLOUD Act betroffen und unterliegen stregeren Datenschutzbestimmungen – was ein weiteres gutes Argument ist.   Grundsätzlich gibt es zwei Möglichkeiten: Entweder Sie wählen einen Anbieter, der Ihnen den Dienst zur Verfügung stellt oder Sie installieren eine Software auf einem eigenen Server. Wer selbst hostet, behält die Hoheit über die eigenen Daten und hat viele Möglichkeiten, die eigene Cloud zu gestalten. Allerdings wird auch einiges technisches Know-How vorausgesetzt. Immerhin benötigen Sie einen eigenen Server, müssen diesen einrichten und selbst betreuen. Beide Varianten besprechen wir in diesem Artikel.

Funktionalität: Natürlich kommt es uns auch auf die Funktionalität an: Werden Clients für die gängigen Betriebssysteme zur Verfügung gestellt? Funktionieren diese schnell und vor allem zuverlässig? Wie sieht es mit Apps fürs Smartphone aus? Was können diese? Wir fragen uns auch, wie das Teilen von Dateien mit Dritten funktioniert und ob dies per Ende-zu-Ende-Verschlüsselung möglich ist. Außerdem interessieren wir uns für Zusatzfeatures wie eine Versionsverwaltung (alte Dateien wiederherstellen können), Bildervorschau und Galerie im Browser sowie in den Apps, Kamera-Upload-Funktion in der App und Office-Plugins für den Browser. Des Weiteren bieten manche Anbieter Zusatzfunktionen an, die über die Dateiverwaltung hinaus gehen: Verwaltung von Passwörtern, Kalender, Adressbuch und To-Do-Listen, um einpaar zu nennen.

[iheu_ultimate_oxi id=”1″]

Testbericht

SpiderOak One Backup

SpiderOak ist ein von Edward Snowden empfohlener Dienst, der für Windows, macOS, Linux, Android, iOS und im Browser zur Verfügung steht. Auf den ersten Blick bietet er Ende-zu-Ende Verschlüsselung und das Zero-Knowledge Prinzip. Auf den zweiten Blick gibt es jedoch auch ein paar kritische Punkte: So speichert SpiderOak in der USA. Beim Zugriff über mobile Clients oder den Browser wird das Passwort während der Sitzung auf dem SpiderOak-Server gespeichert. Der Speicher ist verschlüsselt. Nach Abschluss der Sitzung wird das Passwort gelöscht. Die Entschlüsselung erfolgt hier bereits auf dem Server, das Zero-Knowledge-Prinzip streng genommen durchbrochen wird.

Funktionsumfang

Die Anzahl der Geräte, die man nutzen möchte ist nicht beschränkt. Das Teilen von Dateien und Ordnern ist passwortgeschützt und als so genannter ShareRoom möglich. Um Inhalte mit anderen zu teilen, kann ein Link versendet werden. Auch hier erfolgt die Entschlüsselung bereits auf dem Server. Ausnahmen bilden die Nutzung im Browser und auf mobilen Geräten: Hier werden nur rudimentäre Funktionen zur Verfügung gestellt. Es kann durch Ordnerstrukturen navigiert werden und Dateien können heruntergeladen werden. Es ist nicht möglich, Dateien hochzuladen oder zu teilen. Eine Synchronisation ist auf mobilen Geräten ebenfalls nicht möglich. Außerdem gibt es keine Explorer/Dateimanager-Integration, die den Synchronisationsstatus von Dateien anzeigt.

TresorIT

Tresorit ist ein schweizer Anbieter, der in Irland und den Niederladen hostet. Das ist ein Pluspunkt in Sachen Datenschutz und Sicherheit. Es werden Clients für Windows, macOS, Linux, Android, iOS, Windows Phone und Blackberry geboten. Auch der Zugriff per Browser ist möglich. Der Anbieter bietet Ende-zu-Ende Verschlüsselung und das Zero-Knowledge Prinzip. Es gibt die Möglichkeit einer Zwei-Faktor-Authentifizierung per Authentikator-App, SMS, Telefonanruf oder E-Mail, um den Account zusätzlich vor unberechtigten Zugriffen zu schützen.

Kleiner Wehmutstropfen für den Datenschutzbewussten: Auf den Informationsseiten zur Cloud ist Google Analytics eingebunden (Tracking). Beginnend mit der Loginseite ist das jedoch passé. Man wird also bei der täglichen Arbeit mit der Cloud nicht ständig verfolgt. Wir haben den Anbieter dennoch angeschrieben und auf diesen Makel hingewiesen.

Funktionsumfang

Per Brower steht der volle Funktionsumfang zur Verfügung. Dateien werden hier vom Browser clientseitig entschlüsselt, sodass eine Ende-zu-Ende Verschlüsselung sichergestellt ist.

Praktisches Feature: Zu Bildern werden Vorschaubilder angezeigt und das Navigieren durch eine Bildergalerie ist möglich.
Die App stellt alle Features von Tresorit zur Verfügung. Dateien können direkt geöffnet werden oder innerhalb von Tresorit offline verfügbar gemacht werden. Einzelne Dateien können auch heruntergeladen und in einem beliebigen Ordner gespeichert werden. Leider ist es nicht möglich, ganze Ordner herunterzuladen. Auch fehlt die Möglichkeit zur Synchronisation von Ordnern mit einem Tresor, wie es auf dem Desktop möglich ist. Mit der Kamera-Upload-Funktion können Fotos oder Videos automatisch hochgeladen werden. Auch die App bietet Vorschaubilder für Fotos und ermöglicht das Navigieren durch eine Bildergalerie. Der Windows- und Linux Client funktionierte im Test schnell und fehlerfrei. Es gibt allerdings keine Explorer/Dateimanager-Integration, die den Synchronisationsstatus der Dateien anzeigt. Das Teilen von Dateien und Ordnern ist passwortgeschützt und kann optional mit einem Ablaufdatum versehen werden. Auch hier greift die Ende-zu-Ende-Verschlüsselung. Außerdem ist das Teilen von Tresoren mit anderen Tresorit-Mitgliedern möglich, die, wenn gewünscht, auch Schreibzugriff erhalten können. Bis zu 10 Geräte können synchronisiert werden.

SecureSafe

SecureSafe ist ein schweizer Anbieter und speichert vor Ort. Damit unterliegen die Daten dem vergleichsweise strengem schweizer Datenschutzgesetz. Es gibt Clients für Windows, macOS, iOS, Android. Leider fehlt ein Linux-Client. SecureSafe bietet Ende-zu-Ende Verschlüsselung und das Zero-Knowledge Prinzip. Es besteht die Möglichkeit, eine Zwei-Faktor-Authentifizierung per SMS (mTAN) zu nutzen.

Kleiner Wehmutstropfen für den Datenschutzbewussten: Auf den Informationsseiten zur Cloud ist Google Analytics eingebunden (Tracking). Beginnend mit der Loginseite ist das jedoch passé. Man wird also bei der täglichen Arbeit mit der Cloud nicht ständig verfolgt. Wir haben den Anbieter dennoch angeschrieben und auf diesen Makel hingewiesen.

Funktionsumfang

Die Anzahl der Geräte, die man nutzen möchte ist nicht beschränkt. Als Zusatzfunktion gibt es einen Passwort-Safe, als sicheren Ablageort für Passwörter. Dieser ist per Browser, Desktop- und Mobile-App zugreifbar. Per Browser steht der volle Funktionsumfang zur Verfügung, einschließlich Ende-zu-Ende-Verschlüsselung.

Praktisches Feature: Zu Bildern werden per Klick Vorschaubilder angezeigt und es ist möglich durch eine Bildergalerie zu navigieren. Vorschaubilder direkt in der Dateiübersicht gibt es leider nicht, es muss zuerst eine Datei ausgewählt werden. Auch zu PDF-Dateien wird eine Vorschau, allerdings können PDFs nicht direkt im Browser betrachtet werden.

Der Windows-Client funktionierte im Test nicht fehlerfrei. Zum Teil wurden Dateien vom Desktop nicht in die Cloud übertragen. Und es gibt keine Explorer/Dateimanager-Integration, die den Synchronisationsstatus der Dateien anzeigt.

In der SecureSafe-App stehen alle Features zur Verfügung. Dateien können direkt geöffnet oder heruntergeladen werden. Zumindest unter Android stellt sich das Herunterladen unnötig kompliziert dar. Denn es muss jedes Mal ein externer Dateimanager ausgewählt und aufgerufen werden. Leider ist es nicht möglich ganze Ordner herunterzuladen. Auch fehlt die Möglichkeit zur Synchronisation von Ordnern. Eine Kamera-Upload-Funktion stellt die App nicht zur Verfügung. Außerdem fehlt die Möglichkeit regelmäßig Daten zu synchronisieren; Was mit der Desktop-Version möglich ist.
Gut zu wissen: Nutzende werden nach einer bestimmten Zeit, in der das Smartphone im Standby ist oder sich die App im Hintergrund befindet, ausgeloggt – maximal 30 Minuten. In der App fehlt die Möglichkeit zur regelmäßigen Synchronisation der Daten, wie es auf den Desktop möglich ist. Dateien können geteilt werden, der Link kann direkt per Browser als E-Mail weitergegeben werden. Hierbei wird ein Sicherheitscode (Passwort) generiert, das man sich entweder angezeigen lassen kann oder direkt per SMS empfangen. Das Teilen ganzer Ordner ist leider nicht möglich.

Your Secure Cloud

Your Secure Cloud ist ein deutscher Anbieter, der auch in Deutschland speichert. Im Hinblick auf Sicherheit und Datenschutz ist dies für deutsche Nutzer.innen optimal. Es gibt Clients für Windows, macOS, Linux, einen Terminal-Client, Android und iOS. Der Anbieter bietet Ende-zu-Ende Verschlüsselung mit AES-256 und das Zero-Knowledge Prinzip. Großer Vorteil: Der Anbieter basiert auf dem Open-Source-Client (GPLv2) und -Server des SeaFile Projekts. Die hier beschriebene Funktionalität kann also auch auf einem eigenem Server selbst gehostet werden.

Funktionsumfang

Die Anzahl der Geräte, die man nutzen möchte ist nicht beschränkt. Die Struktur basiert auf so genannten Bibliotheken, in denen Dateien abgelegt werden können. Es kann entsprechend auf jedem Client ausgewählt werden, welche Bibliotheken synchronisiert werden. Es ist darauf zu achten, dass die standardmäßig angelegte Bibliothek keine Ende-zu-Ende-Verschlüsselung unterstützt. Denken Sie daher daran, eine neue und verschlüsselte Bibliothek mit Passwortschutz zu erstellen. Es gibt ein Versionsverwaltungssystem, d.h. man kann sich ältere Versionen einer Datei anschauen und auch wiederherstellen. Das ist sehr praktisch beim Bearbeiten von Dokumenten. Auch versehentlich gelöschte Dateien können bis zu 60 Tage lang wiederhergestellt werden.
Per Browser steht der volle Funktionsumfang zur Verfügung, einschließlich Ende-zu-Ende-Verschlüsselung. Praktisches Feature: Zu Bildern werden Vorschaubilder angezeigt und man kann durch eine Bildergalerie navigieren. Videos können direkt im Browser abgespielt werden. Als Besonderheit ist hier das Erstellen und Editieren von Markdowndateien und Microsoft Office Dateien – Word, Excel, PowerPoint – möglich. Die Untersützung ist sehr umfangreich. Das Speichern von Microsoft Office-Dateien funktionierte in unserem Test allerdings nicht immer fehlerfrei. Zudem können PDFs und OpenDocument-Dateien nur betrachtet werden.

Für den Desktop werden zwei Clients zur Verfügung gestellt: Ein Sync-Client, der die Dateien auf der lokalen Festplatte synchronisiert und ein Netzlaufwerk-Client, der den Fernzugriff ermöglicht, ohne die Daten lokal zu halten. Der Desktop-Client funktionierte unter Windows wie Linux zuverlässig und synchronisiert schnell. Es gibt eine Explorer/Dateimanager-Integration, die den Synchronisationsstatus der Dateien anzeigt. Unter Windows 7 gab es in unserem Test Probleme bei der Installation, die wir jedoch lösen konnten. Unter Windows 10 gab es keine Probleme. Unter Linux funktionierte das Netzlaufwerk ebenfalls zuverlässig. Es fiel allerdings auf, dass wir nicht auf verschlüsselte Bibliotheken zugreifen konnten. Nach Angabe der Betreiber soll dies zukünftig möglich sein.
Die App stellt alle Features von Your Secure Cloud zur Verfügung. Dateien können direkt geöffnet oder heruntergeladen werden. Sie erscheint dann im Seafile-Ordner, der im Root-Verzeichnis des Smartphones liegt. Es ist auch möglich, ganze Ordner herunterzuladen. Es fehlt die Möglichkeit zur Daten regelmäßig zu synchronisieren, wie es auf dem Desktop möglich ist. Eine Kamera-Upload-Funktion wird zur Verfügung gestellt und es werden Vorschaubilder in der App angezeigt. Auch durch eine Bildergalerie kann man navigieren. Es können sowohl Dateien als auch Ordner geteilt werden, optional auch mit Passwortschutz. Ein entsprechender Link wird generiert. Es ist außerdem möglich, ein Ablaufdatum zu vergeben. Auch können Freigaben für andere Your Secure Cloud-Nutzer .innen erstellt werden, die diese dann in ihrem eigenen Profil sehen können. Wenn gewünscht, können sogar Schreibrechte vergeben werden. Leider ist es nicht möglich, einzelne Dateien bzw. Ordner aus verschlüsselten Bibliotheken zu teilen. Möglich ist hingegen, eine vollständig verschlüsselte Bibliothek für einen anderen Your Secure Cloud-Nutzer.innen freizugeben.

Nextcloud

Nextcloud ist ein selbst gehostetes Projekt, d.h. man setzt das Projekt auf dem eigenen Server auf. Dennoch gibt es auch Anbieter, die die Nextcloud als Drittanbieter fix und fertig zur Nutzung anbieten (siehe dazu weiter unten). Es gibt Clients für Windows, macOS, Linux, Android und iOS. Natürlich ist auch der Zugriff per Browser möglich. Es werden ein Open-Source-Server unter AGPLv3 Lizenz geboten, mobile Clients laufen unter der AGPLv3, Desktop-Clients unter der GPLv2. Zwei-Faktor-Authentifizierung mit mobilem Authentifikator [als Erweiterung] wird geboten. Es ist möglich eine Verschlüsselung auf dem Server einzurichten. Eine Ende-zu-Ende-Verschlüsselung befindet sich in der Entwicklung und ist als Alpha Version verfügbar. Vom Produktivbetrieb wird derzeit noch abgeraten.
Zudem gibt es folgende Einschränkungen:

  • Kein Zugriff auf verschlüsselte Dateien per Browser
  • Verlust des serverseitigen Papierkorbs – Dateien werden direkt gelöscht.
  • Verlust der serverseitigen Suche
  • Verlust von serverseitigen Vorschauen, z.B. Bilder
  • Einzelne Dateien können nicht mehr geteilt werden.

Funktionsumfang

Standardmäßig stellt Nextcloud Möglichkeiten zur Dateiverwaltung zur Verfügung. Erweiterungen bieten jedoch ein viel umfangreicheres Angebot: Kalender, Adressbuch, To-Do-Liste, Passwortmanager, um nur einige zu nennen. Dabei können Kalender auch über das offene CalDAV Protokoll mit dem Smartphone synchronisiert werden. Das Adressbuch kann über CardDAV mit dem Smartphone verbunden werden. Dazu wird auf dem Smartphone ggf. weitere Software benötigt, z.B. das quelloffene DAVx5 für Android. Eine Versionsverwaltung ist mit an Bord.

Im Browser stehen umfangreiche Funktionen zur Verfügung. Nach Angabe der Entwickler wird bei einer Ende-zu-Ende-Verschlüsselung in Kauf genommen, dass Dateien nicht mehr per Browser abgerufen werden können. Vorschaubilder werden angezeigt und es ist möglich durch eine Bildergalerie zu navigieren. Videos können direkt im Browser abgespielt werden. Mittels der optionalen Erweiterungen OnlyOffice oder Callobra Office gibt es umfangreiche Möglichkeiten zur Bearbeitung von MS Office- und OpenOffice-Dokumenten. Mittels Erweiterung können PDFs online betrachtet werden. Unzählige Erweiterungen bieten weitere Möglichkeiten.

Für den Desktop stehen für Windows, Linux, Unix und macOS ein Clients zur Verfügung. Die Synchronisation funktionierte unter Windows und Linux schnell und problemlos. Für Windows gibt es eine Explorer-Integration, unter macOS gibt es eine für den Finder und unter Linux für Nautilus. So wird der Synchronisationsstatus von Dateien und Ordnern sichtbar gemacht. Es ist unter Windows, Linux und MacOS auch möglich, Nextcloud per WebDAV als Netzlaufwerk einzubinden. Für Ende-zu-Ende-verschlüsselte Clouds ist dies prinzipbedingt leider nicht möglich.

Die App stellt umfangreiche Features zur Verfügung. Es können eine oder mehrere Dateien hoch- und heruntergeladen oder auch direkt geöffnet werden. Auch ganze Ordner können heruntergeladen bzw. synchronisiert werden. Die Synchronisation in der Nextcloud-App muss jedoch manuell angestoßen werden. Alternativ gibt es Apps, die per WebDAV eine kontinuierliche Synchronisation auf mobilen Plattformen anbieten – FolderSync für Android sowie WebDAV Nav+ für iOS (kostenpflichtig). Dies funktioniert jedoch leider nicht für eine Ende-zu-Ende-Verschlüsselung. Eine Kamera-Upload-Funktion wird zur Verfügung gestellt. Es werden Vorschaubilder in der App angezeigt und es ist möglich durch eine Galerie zu navigieren. Es können sowohl Dateien als auch Ordner geteilt werden, optional auch mit Passwortschutz. Ein entsprechender Link wird generiert. Es ist außerdem möglich, ein Ablaufdatum zu vergeben. Man kann Inhalte aus der eigenen Cloud auch für andere Nextcloud-Nutzer.innen erstellen. Wenn gewünscht, können sogar Schreibrechte vergeben werden. Das Teilen funktioniert auch Ende-zu-Ende-verschlüsst.

Eine größere Auswahl von Nextcloudanbietern hat Digitalcourage in diesem Artikel im Hinblick auf Datenschutz, Datensicherheit (Backups), Verschlüsselung, Tracking, Finanzierung, Ökostrom und Kundenservice getestet.

OwnCube

OwnCube ist ein NextCloud Anbieter und bietet daher den Funktionsumfang wie oben beschrieben. Die Daten werden serverseitig verschlüsselt gespeichert. Eine Ende-zu-Ende-Verschlüsselung wird nicht zur Verfügung gestellt. Es bleibt abzuwarten, ob dies in Zukunft der Fall sein wird, wenn Nextcloud die Funktionalität als stabil einstuft zur Verfügung stellt. Der Firmensitz ist in Österreich, die Speicherung findet in der EU statt. Zwei-Faktor-Authentifizierung mit mobilem Authentifikator wird geboten.

Funktionsumfang

Der Funktionsumfang entspricht dem von Nextcloud. Als Erweiterung sind ein Kalender, ein Adressbuch, eine Bildergalerie, Audio-Player, ein Board für Notizen, Lesezeichen und eine To-Do-Liste verfügbar.

Fazit

SpiderOak wird zwar von Edward Snowden empfohlen, ist allerdings ein US-Anbieter und bietet Ende-zu-Ende-Verschlüsselung nur eingeschränkt an: Im Browser und in mobilen Apps funktioniert diese Verschlüsselung nicht. Außerdem ist die Funktionalität im Browser und in den Apps stark eingeschränkt (kein Upload). Besser als die Angebote von Dropbox, Google, Microsoft und Co. ist SpiderOak aber allemal.

Tresorit ist in der Schweiz ansässig, hostet in den Niederladen oder Irland, bietet Ende-zu-Ende-Verschlüsselung im Browser, Desktop Anwendung und mobilen Clients und hat einen großen Funktionsumfang. Wer ein Windows Phone oder ein Blackberry besitzt, sollte sich diese Option genauer anschauen, da dies der einzige Anbieter mit entsprechenden Apps in unserem Test ist. Leider ist die verwendete Software nicht Open Source. Wer dem Anbieter vertraut, für den ist er eine Option.

SecureSafe ist ebenfalls in der Schweiz ansässig und hostet auch dort. Ende-zu-Ende-Verschlüsselung wird in der Desktop Anwendung, im Browser und in den Apps geboten. Wir hatten unter Windows allerdings Probleme mit dem Client. Für Linux gibt es leider keine Anwendung. Der Funktionsumfang ist groß, es fehlt eine Kamera-Upload-Funktion. Leider ist auch hier die Software nicht Open Source. Wer dem Anbieter vertraut, für den ist er eine Option.

Your Secure Cloud basiert auf dem quelloffenen Seafile und ist daher Open Source. Die Firma ist in Deutschland ansässig und hostet auch hier. Ende-zu-Ende-Verschlüsselung wird in der Desktop-Anwendung, im Browser und in den Apps geboten. Leider funktioniert das Teilen von Dateien nicht auf verschlüsselten Speicherorten, wie einzelen Dateien oder Ordnern. Es ist hingegen möglich ganze verschlüsselte Bibliotheken zu teilen. Die Versionsverwaltung ist ein besonderes Schmankerl. Wer mit der Einschränkung bezüglich des Teilens von Dateien leben kann, für den ist dieser Anbieter eine empfehlenswerte Alternative.

Schließlich gibt es noch die Möglichkeit, eine Nextcloud selbst zu hosten. Da man die Hoheit über die eigenen Daten behält, ist eine Ende-zu-Ende-Verschlüsselung hier entbehrlich, zumindest wenn die Daten auf der Festplatte verschlüsselt werden. Der Funktionsumfang ist besonders groß: Es wird auch ein Kalender, Adressbuch, Passwortsafe, To-Do-Liste und vieles mehr geboten. Diese können über offene Protokolle auch mit dem Smartphone synchronisiert werden. Auch eine Versionsverwaltung ist dabei. Dies ist die einzige Alternative, für die ein echter Sync-Client für Apps existiert. Für Menschen, die sich technisch in der Lage fühlen, einen eigenen Server zu betreiben und die den Aufwand nicht scheuen, ist eine selbst gehostete Nextcloud die beste Alternative.

Zuletzt haben wir mit Owncube einen Anbieter getestet, der eine Nextcloud hostet. Der Funktionsumfang ist entsprechend groß: Es gibt alles, was die Nextcloud bietet. Als Erweiterungen sind ein Kalender, ein Adressbuch, eine Bildergalerie, ein Audio-Player, ein Board für Notizen, Lesezeichen und eine To-Do-Liste vorinstalliert. Außerdem ist die zugrundeliegende Software Open Source. Der Anbieter kommt aus Österreich und hostet in der EU. Größte Schwäche: Ende-zu-Ende-Verschlüsselung gibt es hier nicht. Wer keine eigene Nextcloud aufsetzen will oder kann, aber die Zusatzfunktionen wie Kalender etc. benötigt, für den mag dieser Anbieter dennoch die beste Wahl sein. Eine größere Auswahl von Nextcloudanbietern hat Digitalcourage in diesem Artikel im Hinblick auf Datenschutz, Datensicherheit (Backups), Verschlüsselung, Tracking, Finanzierung, Ökostrom und Kundenservice getestet.

Zum Newsletter anmelden

[newsletter_form type=”minimal” lists=”undefined” button_color=”undefined”]

Schlussbemerkung

Dieser Artikel ist zuerst im Blog von Digitalcourage erschienen (hier) und wurde hier in überarbeiteter Fassung publiziert. Ich bedanke mich ausdrücklich bei den Mitarbeitern und Ehrenamtlichen, die den Artikel probe gelesen und sinnvolle Verbesserungsvorschläge eingebracht haben.

Titelbild von Sam Schooler

Categories
Administration / Webmaster IT-Security Linux Mailserver

Postfix & Dovecot: TLS-Konfiguration mit automatisch erneuernden Let’s Encrypt Zertifikaten

Täglich gehen zig Millionen Mails durch die Welt. Heute sollte es selbstverständlich sein, vom Mailclient zum Mailserver transportverschlüsselt zu arbeiten: Mails abrufen per IMAP (Dovecot), Mails versenden per SMTP (Postfix). Aber auch die Intra-Mailserverkommunikation (Postfix) sollte heutzutage nach aktuellen Standards verschlüsselt erfolgen.

Noch vor wenigen Jahren war es noch absolut üblich, dass Mailserver unverschlüsselt miteinander kommunizierten. Noch im Januar 2015 kommunizierten nur gut 50% der Mailserver untereinander verschlüsselt. Heute sind es über 90% (Quelle: Google Transparency Report, Stand: Mai 2020). Das wird im Auge vieler Administratoren dennoch nicht genug sein, um unverschlüsselte Kommunikation komplett auszuschließen. Meiner Meinung nach sollten sich große Anbieter wie GMail, Outlook.com, Web.de, Gmx.de, … zusammen schließen und unverschlüsselte Kommunikation konsequent blocken. Unter diesem Druck wäre es nur eine Frage der Zeit, bis schlecht konfigurierte uralt Server verschwinden.

E-Mail Verschlüsselung über die Zeit. Quelle: Google

Inhalt

Hier möchten wir uns nun mit der Konfiguration von Postfix und Dovecot beschäftigen: Wir werden einen Parallelbetrieb von ECDSA / RSA Zertifikaten vorstellen. RSA ist dabei etablierter Standard. ECDSA (Elliptische-Kurven-Kryptografie) ist Cutting-Edge Technologie und wird in Zukunft an Bedeutung gewinnen. Wer diesen Artikel liest, möchte wahrscheinlich auf der Höhe der Zeit sein und schon heute ECDSA einsetzen.

Dabei nutzen wir Let’s Encrypt als Zertifizierungsstelle und acme.sh als ACME Clients Implementierung zum beziehen und installieren von Zertifikaten. acme.sh ist eine Alternative zu certbot, die für unsere Zwecke einige Vorteile bietet. Besonderes Augenmerk habe ich darauf gelegt, dass Zertifikate automatisch erneuert werden, denn schließlich ist ein Let’s Encrypt Zertifikat nur 3 Monate gültig.

Vorwissen

Für diesen Artikel sind Grundkenntnisse im Bereich von Administration von Linuxsevern im Allgemeinen sowie von Mailservern im speziellen zu empfehlen. Außerdem sollte grundsätzlich verstanden sein, was es mit asymmetrischer Kryptografie auf sich hat und warum eine Zertifizierungsstelle wir Let’s Encrypt benötigt wird.

Wir gehen davon aus, dass Sie Postfix und Dovecot bereits im Einsatz haben oder zumindest so weit konfiguriert haben, dass Ihnen nur noch die Verschlüsselung fehlt. Sollte das noch nicht der Fall sein, befolgen Sie bitte ein entsprechendes Tutorial, bevor Sie hier weiter machen.

Als Betriebssystem kommt bei uns Debian 10 (Buster) zum Einsatz. Auf Ubuntu sollte es kaum Unterschiede geben, für andere Distributionen sind evtl. kleinere Anpassungen nötig.

Unsere Umgebung und Programmversionen:

  • Betriebssystem: Debian 10 (Buster)
  • Postfix: 3.4.8 (Befehl: postconf -d mail_version)
  • Dovecot: 2.3.4.1 (Befehl: dovecot --version)
  • OpenSSL: OpenSSL 1.1.1d (10. Sep 2019) (Befehl: openssl version)

Vorarbeiten

RSA- und ECDSA-Schlüsselpärchen

Wir erzeugen nun ein RSA– und ein ECDSA-Schlüsselpärchen, welche wir von der CA Let’s Encrypt mittels eines Zertifikats beglaubigen lassen. Für diesen Zweck verwenden wir das Shell-Skript acme.sh.

acme.sh installieren

Wir klonen zuerst das git-Repository von acme.sh. Falls git nicht installiert ist, holen Sie dies bitte jetzt nach:

sudo apt-get install git

Nun das git klonen und die Installation anstoßen. Es ist zu empfehlen, dies als root-User zu tun:

sudo su
git clone https://github.com/acmesh-official/acme.sh.git
cd ./acme.sh
./acme.sh --install

Der Installer sorgt für drei Dinge:

  1. Erstellt und kopiert acme.sh in das home-Verzeichnis: ~/.acme.sh/. Alle Zertifikate werden später hier abgelegt und dann mittels einer Installationsroutine an ihren Zielort kopiert.
  2. Es wird ein Alias erzeugt: acme.sh=~/.acme.sh/acme.sh
  3. Es wird ein Cronjob angelegt, der ein mal am Tag Zertifikate checkt und, wenn nötig, neu beantragt und automatisch installiert.

Nach der Installation muss das Terminal ein mal neu gestartet werden, damit der Alias acme.sh funktioniert (ggf. neuer Login per ssh). Die Hilfe von acme.sh kann wie folgt aufgerufen werden: acme.sh -h

Zertifikate erzeugen

Wir könnten nun einerseits ein Wildcard Zertifikat generieren, was aber mit zusätzlichen Aufwänden verbunden ist (DNS Challenge) und ggf. sogar ein Sicherheitsrisiko darstellt. Daher sollten wir ein Zertifikat für den MX-Eintrag generieren (hier: mail.occumail.net) und, falls nötig, alias Domains für den IMAP Server (hier: imap.occumail.net) und für den SMTP Server (hier: smtp.occumail.net) anlegen.

Es stellt sich noch die Frage: Läuft auf dem Server ein Webserver wie apache2 oder nginx? Da acme.sh einen eigenen Webserver startet, kommt es natürlich zu einem Konflikt auf Port 80. Daher bauen wir hier einen Pre-Hook ein, der vor Generierung des Zertifikats apache2 stoppt (--pre-hook "service apache2 stop") und einen Post-Hook, der apache2 wieder startet (--post-hook "service apache2 start"). Für nginx geht dies äquivalent.

RSA Zertifikat erzeugen

Für den RSA Schlüssel empfiehlt das BSI (Bundesamt für Sicherheit in der Informationstechnik) noch bis Ende 2023 eine Schlüssellänge von 2048 Bits, die als sicher gelte. Danach werden 3072 Bits empfohlen. Nachzulesen in der Sicherheitsrichtlinie BSI TR-02102-1 (Stand: 24. März 2020). Wer nach aktuellem Kenntnisstand sicher sein möchte, wählt also 2048 Bits , wer für die Zukunft gewahrt sein möchte 3072 Bits und wer paranoid ist 4096 Bits. Man bedenke bei der Wahl immer, dass ein längerer Schlüssel einen (womöglich deutlichen) Rechenaufwand bedeutet. Bei schwacher Hardware oder schwachen VServern sollte man daher vorsichtig sein, einen zu langen Schlüssel zu wählen. Wir nehmen in unserem Beispiel 3072 Bits (Parameter--keylength 3072).

Nun testen wir erst mal, ob unsere Zertifikatsbeantragung funktioniert. Mit der Option --test wird vorerst nur ein Dummy-Zertifikat erzeugt. Wir sollten vorsichtig vorgehen und nicht ohne Tests arbeiten, da Beantragungen bei Let’s Encrypt auf 5 Ausstellungen pro Woche pro (Sub-)Domain beschränkt sind. Es darf also nicht zu oft schief gehen.

Wir führen also folgendes aus:

acme.sh --pre-hook "service apache2 stop" \
--post-hook "service apache2 start" \
--issue \
-d mail.occumail.net \
-d imap.occumail.net \
-d smtp.occumail.net \
--keylength 3072 \
--standalone \
--test

Hat alles geklappt? Dann nun das echte Zertifikat beantragen:

acme.sh --pre-hook "service apache2 stop" \
--post-hook "service apache2 start" \
--issue \
-d mail.occumail.net \
-d imap.occumail.net \
-d smtp.occumail.net \
--keylength 3072 \
--standalone

Es liegen nun unter ~/.acme.sh/mail.occumail.net folgende Dateien:

  • mail.occumail.net.csr: Certificate Signing Request mit den notwendigen Informationen, die zur Antragsstellung des Zertifikats bei Let’s Encrypt benutzt wurden.
  • mail.occumail.net.csr.conf: Konfigurationsdatei für die zukünftige Generierung von CSRs beim automatischen erneuern von Zertifikaten.
  • mail.occumail.net.cer: Unser Zertifikat für die beantragten (Sub-)Domains.
  • fullchain.cer: Zertifikat für die beantragten (Sub-)Domains zusammen mit Zwischenzertifikaten, die für die Chain of Trust benötigt werden. Diese Datei benötigen wir im Folgenden noch.
  • mail.occumail.net.key: Unser privater Schlüssel. Auch diese Datei benötigen wir noch.
  • ca.cer: Zertifikat der Certification Authority, also Let’s Encrypt.
  • mail.occumail.net.conf: Informationen für die neue Beantragung von Zertifikaten, wenn das Alte abläuft (alle 2 Monate)

Ein Vorteil von acme.sh im Vergleich zu certbot ist, dass der private Schlüssel nicht bei jeder Neubeantragung neu erzeugt wird. Das ermöglicht, die Zertifikate auch für TLSA-Records (DANE) und HPKP (Public Key Pinning) einzusetzen. Wer mit diesen Begriffen jetzt nichts anfangen kann, sollte sich diese nach Abschluss des Tutorials noch mal zur Gemüte führen, da sie für Mailserver durchaus relevant sind.

ECDSA Zertifikat erzeugen

Nun zum ECDSA (Elliptic Curve Digital Signature Algorithm). Let’s Encrypt stellt uns stand heute zwei Varianten zur Verfügung: ec-256 mit 256 Bit Schlüssellänge und ec-384 mit 384 Bit Schlüssellänge. Hier entspricht ec-256 bereits einer RSA-Schlüssellänge von 3072 Bit und ist damit auch auf längere Sicht hinreichen sicher (über Jahr 2023 hinaus). ec-384 entspricht einer RSA-Schlüssellänge von 7680 Bit und ist damit quasi auf Ewig unknackbar (Fehler im Algorithmus und unerwartete Technologiesprünge ausgenommen). Da diese Art von Algorithmus ob des ohnehin relativ kurzen Schlüssels sehr effizient ist, spricht aus Performancegründen aber auch kaum etwas gegen den Einsatz von ec-384.

Zur Generierung führen wir Äquivalent zu oben folgendes aus:

acme.sh --pre-hook "service apache2 stop" \
--post-hook "service apache2 start" \
--issue \
-d mail.occumail.net \
-d imap.occumail.net \
-d smtp.occumail.net \
--keylength ec-384 \
--standalone \
--test

Wenn alles funktioniert hat, dann wieder ohne --test:

acme.sh --pre-hook "service apache2 stop" \
--post-hook "service apache2 start" \
--issue \
-d mail.occumail.net \
-d imap.occumail.net \
-d smtp.occumail.net \
--keylength ec-384 \
--standalone

Es wird der Ordner ~/.acme.sh/mail.occumail.net_ecc erzeugt. Darin enthalten sind die gleichen Dateien wie für den RSA Fall.

Zertifikate Installieren

Nun müssen wir die Zertifikate noch installieren, d.h. von ~/.acme in die richtigen Zielordner verschieben. Auch das übernimmt acme.sh für uns. Wir benötigen den Private Key und unser Zertifikat einschließlich Chain of Trust. Außerdem müssen sowohl Postfix als auch Dovecot nach Abschluss neu gestartet werden, insbesondere auch beim automatischen Ausstellen neuer Zertifikate. Die Berechtigungen für die kopierten Dateien werden von acme.sh automatisch auf 600 gesetzt, sodass ein Zugriff nur vom Besitzer der Datei möglich ist.

Der Code für RSA:

acme.sh --install-cert -d mail.occumail.net \
--key-file /etc/ssl/private/mail.occumail.net.key \
--fullchain-file /etc/ssl/certs/mail.occumail.net.cer \
--reloadcmd "service postfix restart; service dovecot restart"

Und für ECDSA:

acme.sh --install-cert -d mail.occumail.net \
--key-file /etc/ssl/private/mail.occumail.net_ecc.key \
--fullchain-file /etc/ssl/certs/mail.occumail.net_ecc.cer \
--reloadcmd "service postfix restart; service dovecot restart" \
--ecc

Auch diese Operationen werden in der Datei ~/.acme.sh/mail.occumail.net/mail.occumail.net.conf bzw. ~/.acme.sh/mail.occumail.net_ecc/mail.occumail.net.conf persistiert, sodass das Installieren von Zertifikaten in Zukunft ebenfalls automatisiert erfolgt.

3.2 (E)DH-Key erzeugen

Postfix nutzt Forward Secrecy bereits ohne weitere Konfiguration. Allerdings werden für den Schlüsselaustausch via Forward Secrecy geeigneten Cipher-Suiten (EDH) bereits vorberechnete DH-Schlüssel mit 2048-Bit und 512-Bit verwendet. Wir berechnen einen neuen Schlüssel.

Das BSI empfiehlt aktuell noch einen Key mit mindestens 2048 Bits. Ab dem Jahr 2022 sollen Keys mit einer Größe von mindestens 3072 Bits verwendet werden. Nachzulesen in der Sicherheitsrichtlinie BSI TR-02102-1 (Stand: 24. März 2020). Die ganze sicheren unter uns können dann noch 4096 Bits einsetzen. Ich habe mich für den Mittelweg entschieden und damit langfristig vorgesorgt.

Die Generierung kann wie folgt angestoßen werden:

openssl dhparam -out /etc/postfix/dh_3072.pem -2 3072

TLS-Konfiguration von Postfix

Unter GNU/Linux finden Sie die zentrale Konfigurationsdatei von Postfix unter:

/etc/postfix/main.cf

Hier finden Sie mehrere Paramater der folgenden Form:

  • Ist smtp_XXX vorangestellt, gelten die Einstellungen für das Versenden von E-Mails. Also E-Mails, die Postfix an einen anderen Mailserver versendet.
  • Ist smtpd_XXX vorangestellt, geht es um zu unserem Server eingehende Mails. Also E-Mails, die Postfix von einem anderen Mailserver empfängt.

Wir konfigurieren Postfix für eingehende Mails wie folgt:

smtpd_tls_security_level = may
#smtpd_tls_security_level = encrypt
smtpd_tls_cert_file = /etc/ssl/certs/mail.occumail.net.cer
smtpd_tls_key_file = /etc/ssl/private/mail.occumail.net.key
smtpd_tls_eccert_file = /etc/ssl/certs/mail.occumail.net_ecc.cer
smtpd_tls_eckey_file = /etc/ssl/private/mail.occumail.net_ecc.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_ciphers = high
smtpd_tls_mandatory_ciphers = high
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_ciphers = high
smtpd_tls_dh1024_param_file = /etc/postfix/dh_3072.pem
smtpd_tls_received_header = yes
smtpd_tls_eecdh_grade = ultra
smtpd_tls_loglevel = 1
  • smtpd_tls_security_level: may bedeutet, dass standardmäßig verschlüsselt werden soll, aber unverschlüsselte Verbindungen als Fallback zugelassen werden. encrypt bedeutet, dass Verschlüsselung erzwungen wird. Letzteres wäre eigentlich wünschenswert, aber, wie bereits weiter oben beschrieben, verschlüsseln derzeit (Mai 2020) “nur” etwa 90% der Mailserver ihre Verbindung. Es könnten also Mails abgewiesen werden, was dem Sender jedoch mitgeteilt wird. Im Allgemeinen wird (noch) empfohlen hier may zu wählen. Idealisten mögen encrypt bevorzugen.
  • smtpd_tls_cert_file: Unser Zertifikat für RSA
  • smtpd_tls_key_file: Unser Private Key für RSA
  • smtpd_tls_eccert_file: User Zertifikat für ECDSA
  • smtpd_tls_eckey_file: User Private Key für ECDSA
  • smtpd_tls_session_cache_database: Ein Cache für User Sessions. Steigert die Performance von Loginprozessen.
  • smtpd_tls_ciphers: Stärke der Kryptografie bei opportunistischer Kryptografie (smtpd_tls_security_level=may) Der Standardwert ist hier medium und ermöglicht auch die Kommunikation mit veralteten Mailservern. Der Wert sollte auf high gesetzt werden. Wir werden später noch anpassen, welche Chiphers bei high erlaubt sind. Im Zweifelsfall ist es nicht schlimm den Wert high zu nehmen, denn wir haben im Notfall immernoch ein Fallback auf unverschlüsselte Kryptografie.
  • smtpd_tls_mandatory_ciphers: Stärke der Kryptografie bei erzwungener Verschlüsselung (smtpd_tls_security_level=encrypt). Hier sollte eventuell überdacht werden, ob medium eine gute Wahl ist, weil Mails evtl. abgewiesen werden, wenn der Kommunikationspartner keine starke Verschlüsselung untersützt. Idealisten sollten hier trotzdem bei high bleiben. Irrelevant, falls (smtpd_tls_security_level=may).
  • smtpd_tls_protocols: Hier werden alte Protokolle wie SSLv2 (1995), SSLv3 (1996), TLS 1.0 (1999) und TLS 1.1 (2006) augeschlossen. Dies entspricht den aktuellen Empfehlungen. Es bleiben die aktuelle TLS 1.3 Spezifikation von 2018 und als Fallback TLS 1.2 von 2008, welches auch noch als hinreichend sicher gilt. Gilt für (smtpd_tls_security_level=may).
  • smtpd_tls_mandatory_protocols: Protokolle bei smtpd_tls_security_level=encrypt.
  • smtpd_tls_dh1024_param_file: Der Diffie-Hellman Schlüssel, den wir in einem vorherigen Schritt erzeugt haben. Wir ersetzten hier den standardmäßigen 1024 Bit Schlüssel durch einen 2048, 3072 oder 4096 Bit großen Schlüssel (je nach dem, wie Sie sich entschieden haben).
  • smtpd_tls_received_header: Fügt jeder E-Mail einen Header hinzu, welche Kryptografie zum Empfang der Mail verwendet wurde. Für Interessierte.
  • smtpd_tls_eecdh_grade: Sicherheit bei EECDH (elliptische Kurven Kryptografie). Im Default hier strong, was eine 128-bit Sicherheit verspricht. Bei ultra werden 192-bit verwandt, was zusätzliche Sicherheit verspricht. Der Rechenaufwand ist hier etwa doppelt so hoch wie bei 128-bit.
  • smtpd_tls_loglevel: Loglevel für TLS Aktivitäten. Wert zwischen 0 und 4. Bei 1 wird ein guter Trade-Off erreicht. Höhere Werte loggen sehr viel und werden unübersichtlich.

Wir konfigurieren Postfix für ausgehende Mails wie folgt:

Die Konfiguration ist ähnlich zu der obigen zu lesen, nur dass es hier um ausgehende Mails geht:

smtp_tls_security_level = may
#smtp_tls_security_level = encrypt
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_ciphers = high
smtp_tls_mandatory_ciphers = high
smtp_tls_loglevel = 1

TLS Konfiguration

tls_high_cipherlist = !aNULL:!eNULL:!CAMELLIA:HIGH:@STRENGTH
tls_preempt_cipherlist = yes
tls_ssl_options = NO_COMPRESSION

Die hier angegebene tls_high_cipherlist ist ein guter Kompromiss mit Fokus auf starke Kryptografie. Bei ImmuniWeb erhält man mit dieser Konfiguration eine A+ Rating (Stand Mai 2020). Wer es ausprobieren möchte: Server mit Port angeben (z.B. occumail.net:25). Bei CryptCheck erhält man ein A Ranking (96 von 100 Punkte).

tls_preempt_cipherlist sagt aus, dass der Server die Präferenzen bei der Cipher setzt und nicht auf ggf. vom Client kommende Präferenzen reagiert.

tls_ssl_options sollte auf NO_COMPRESSION aus Sicherheitsgründen auf NO_COMPRESSION gesetzt werden (BREACH, CRIME).

Nicht vergessen: Zum Schluss ein mal Postfix neu starten:

service postfix restart

TLS-Konfiguration von Dovecot

Dovecot hat für die SSL-Konfiguration eine Extra Konfigurationsdatei:

/etc/dovecot/conf.d/10-ssl.conf

Wir konfigurieren diese wie folgt:

ssl = required
ssl_cert = </etc/ssl/certs/mail.occumail.net.cer
ssl_key = </etc/ssl/private/mail.occumail.net.key
ssl_alt_cert = </etc/ssl/certs/mail.occumail.net_ecc.cer
ssl_alt_key = </etc/ssl/private/mail.occumail.net_ecc.key
ssl_client_ca_dir = /etc/ssl/certs
ssl_dh = </etc/postfix/dh_3072.pem
ssl_min_protocol = TLSv1.2
ssl_cipher_list = !aNULL:!eNULL:!CAMELLIA:HIGH:@STRENGTH
ssl_prefer_server_ciphers = yes
  • ssl: Sollte auf required stehen, sodass Verschlüsselung erzwungen wird. Eigentlich gibt es keinen ernst zu nehmenden Mailclient mehr, der die hier eingesetzte Verschlüsselung nicht unterstützt. Da wir nur das Beste für unsere Nutzer wollen, erzwingen wir daher Verschlüsselung. Wer einen Mailclient nutzt, der hier nicht funktioniert, der sollte lieber gebeten werden den Client zu wechseln als die Dovecot-Konfiguration anzupassen.
  • ssl_cert: Unser RSA Zertifikat
  • ssl_key: Unser RSA Private Key
  • ssl_alt_cert: Unser ECDSA Zertifikat als Alternative zu RSA
  • ssl_alt_key: User ECDSA Private Key als Alterntaive zu RSA
  • ssl_client_ca_dir: Liste vertrauter Zertifizierungsstellen. Wird durch das Betriebssystem unter /etc/ssl/certs zur Verfügung gestellt.
  • ssl_cipher_list: Unsere Ciphers. Wie bei Postfix auch.
  • ssl_dh: Der Diffie-Hellman Schlüssel, den wir vorhin schon für Postfix generiert haben. Je nach dem, dh_2048.pem, dh_3072.pem, dh_4096.pem
  • ssl_min_protocol: Minimale TLS Version. Mit der Angabe TLSv1.2 schließen wird SSLv2, SSLv3, TLS 1.0 und TLS 1.1 aus. TLS 1.3 ist natürlich zugelassen.
  • ssl_cipher_list: Die unterstützen Ciphers. Wie bei Postfix.
  • ssl_prefer_server_ciphers: Auswahl der Ciphers durch Server vor Cliententscheidung bevorzugen.

Damit wären wir auch schon fertig. Nicht vergessen, Dovecot neu zu starten:

service dovecot restart

Fazit

Nun haben wir es geschafft: Eine sichere Konfiguration von Postfix und Dovecot mit ausreichend Abwärtskompatibilität. Außerdem haben wir mit ECDSA-Zertifikaten aktuellste Kryptografie, die in Zukunft sicherlich vermehrt zum Einsatz kommen wird. Zudem erneuern sich unsere Zertifikate automatisch.

Ergebnisse für occumail.net von CryptCheck. Stand: 02.05.2020
Ergebnisse für occumail.net von ImmuniWeb. Stand: 02.05.2020
Categories
Administration / Webmaster German IT-Security Linux

Optimale TLS-Sicherheit mit Abwärtskompatibilität für Apache bei Qualys SSL Labs und co.

Viele kennen sicherlich den SSL Report von Qualys SSL Labs. Nun möchte man natürlich gute Ergebnisse bzgl. Sicherheit erzielen, aber kann auch nicht die Abwärtskompatibilität völlig außer Acht lassen. Ich versuche hier einen nach aktuellem Stand guten Trade-Off vorzustellen. Außerdem möchten wir auch im CryptCheck, ImmuniWeb SSL Security Test, DigiCert® SSL Installation Diagnostics Tool und SSL-Tools Check gut abschneiden. In diesem Tutorial setze ich auf Debain, apache2 und certbot. Ähnliches lässt sich natürlich auch mit nginx und/oder acme.sh erreichen.

Grundlage für diesen Artikel war folgende Konfiguration:

  • Debian 10
  • Apache 2.4.38 (Befehl: apache2 -v)
  • certbot 0.31.0 (Befehl: certbot --version)
  • openssl 1.1.1d (Befehl: openssl version)

Zertifikat mit certbot erzeugen

Wer certbot noch nicht installiert hat, möge das nach der einfachen Anleitung auf der certbot-Homepage tun. Kommen wir nun erst mal zur Generierung und der Installation des Zertifikats. Während sich Qualys mit 2048 Bit RSA Zertifikaten zufrieden gibt, erhalten wir bei CryptCheck damit nur eine durchschnittliche Bewertung. Für den RSA Schlüssel empfiehlt das BSI (Bundesamt für Sicherheit in der Informationstechnik) noch bis Ende 2023 eine Schlüssellänge von 2048 Bits, die als sicher gelte. Danach werden 3072 Bits empfohlen. Nachzulesen in der Sicherheitsrichtlinie BSI TR-02102-1 (Stand: 24. März 2020). Wir wählen hier 3072 Bits, weil das einem guten Kompromiss aus Sicherheit und Performance entspricht (Paramater --rsa-key-size 3072). Wer noch eins drauf setzten möchte, kann natürlich auch 4096 Bits nehmen.

Auf jeden Fall benötigen wir noch HTTP Strict Transport Security (HSTS). Dabei handelt es such um einen HTTP Header, der z.B. durch Apache gesetzt werden kann, und aussagt, dass diese Seite (für einen sehr langen Zeitraum) vom Browser nur noch per https aufgerufen werden darf. Unverschlüsselter Datenverkehr wird also für die Zukunft ausgeschlossen. Der Paramater lautet --hsts. Außerdem sollten wir eine Weiterleitung von http auf https einrichten. Auch das tut certbot für uns (Paramater --redirect). Der Befehl lautet also wie folgt:

certbot --apache --rsa-key-size 3072 --hsts --redirect

Wahl der Protokolle und Cipher-Suites

certbot hat nun für uns die Datei /etc/letsencrypt/options-ssl-apache.conf erzeugt, die wie wie folgt editieren:

SSLEngine on

# Intermediate configuration, tweak to your needs
SSLProtocol             all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384
SSLHonorCipherOrder     on
SSLCompression          off

Als SSL-Protokolle müssen wir in jedem Fall TLS 1.0 und TLS 1.1 herausnehmen, da wir seit Januar 2020 bei Qualys auf Grad B gestutzt werden. Es verbleiben die sicheren Versionen TLS 1.2 und TLS 1.3. Diese Protokolle gelten als nicht mehr hinreichend sicher. Die Wahl der Chipher-Suits war eine lange Suche und ausprobieren. Sie sorgen in Qualys dafür, dass wir einen sehr guten A+ Rank erhalten, aber keine Hanshake Simulation fehlschlägt. Auch ImmuniWeb verpasst uns einen A+ Rank. Auch bei CryptCheck erhalten wir eine A+ Raking mit 93/100 Punkten. Hätten wir RSA mit 4096 Bits genutzt, wäre CryptCheck mit 96/100 Punkten übrigens noch ein bisschen Glücklicher gewesen, weil wir 100/100 beim Schlüsselaustausch bekommen hätten. Ich halte das allerdings für etwas übertrieben.

A+ Ranking beim SSL Report von Qualys SSL Labs
A+ Ranking mit 93/100 Punkten bei CryptCheck mit 3072 Bit Zertifikat
A+ Ranking bei CryptCheck mit 96/100 Punkten mit 4096 Bit Zertifikat
A+ Rank beim ImmuniWeb SSL Security Test

Und darüber hinaus?

Abschließend sollte man noch mal über DNS Certification Authority Authorization nachdenken. Der Folgende DNS Eintrag besagt, dass unser Zertifikat von Let’s Encrypt stammen muss und sorgt so für noch etwas mehr Sicherheit:

the-digital-native.de. CAA 128 issue "letsencrypt.org"

Wir haben es also geschafft: Ein Top Security Rank in allen mir bekannten Tests. Wer jetzt noch etwas mehr tun möchte, kann sich noch über DANE bzw. einen TLSA DNS-Eintrag Gedanken machen. Hier wird ein Hash des eigenen Zertifikats als DNS Eintrag hinterlegt, sodass das Zertifikat nicht unbemerkt ausgetauscht werden kann. Hier gibt es einen Generator dafür.

Auch einen Blick wert ist das Mozilla Obversatory, welches einem vor allem Vorschläge für diverse HTTP-Header macht. Für einfache Seiten ist dies relativ einfach umzusetzen, aber für CMS Software wie WordPress wird es schon schwieriger. In einem zukünftigen Artikel habe ich vor, mich mit dem Content Security Policy Header für WordPress zu beschäftigen. Stay Tuned!