thomas-leister.de

Restic mit Hetzner Storagebox nutzen

thomas.leister@mailbox.org (Thomas Leister) — Sat, 07 Sep 2019 12:11:00 +0200

Die flexiblen und günstigen Storage Boxes von Hetzner eigenen sich wunderbar für Backups von Servern und Desktoprechnern. Ich nutze sie, um verschlüsselte Sicherungen meiner Server geografisch getrennt und sicher aufzubewahren. Das Backup-Tool Restic spielt dabei über das SFTP-Protokoll wunderbar mit dem Cloudspeicher zusammen.

Bevor die StorageBox mit Restic verknüpft werden kann, muss die Box zunächst vorbereitet werden, sodass auf sie via SFTP zugegriffen werden kann. In den StorageBox Einstellungen muss das SSH-Protokoll zur Datenübertragung aktiviert sein. Alle anderen Zugriffsmethoden wie z.B. Samba können deaktiviert bleiben.

Danach wird die StorageBox lokal gemoutet, um alle weiteren Vorbereitungen zu treffen.

mkdir /mnt/storagebox
sshfs u123456@u123456.your-storagebox.de: /mnt/storagebox/

(u123456 muss hier und in den folgenden Kommandos durch die eigene Userkennung ersetzt werden!)

Gebt das Passwort für die StorageBox ein. Das Passwort kann in den Einstellungen der StorageBox eingesehen bzw. geändert werden.

Für eine Authentifizierung des Servers an der StorageBox soll ein SSH-Key genutzt werden. Damit der passende Public Key an der StorageBox registriert werden kann, muss ein .ssh Verzeichnis und die authorized_keys Datei angelegt werden.

mkdir /mnt/storagebox/.ssh
touch /mnt/storagebox/.ssh/authorized_keys

Einen neuen Host registrieren

Nun wird auf dem zu sichernden Server ein neuer SSH-Key für den root-User generiert. Achtet darauf, für den Key kein Passwort anzulegen - schließlich soll der Key einmal während des Backupprozesses automatisch und ohne Passworteingabe verwendet werden.

ssh-keygen -t ed25519

In der SSH-Konfigurationsdatei /root/.ssh/config des Servers wird folgende Konfiguration hinterlegt:

Host u123456.your-storagebox.de
User u123456
Port 23

Die Konfiguration wird später einen konfortableren Zugriff ermöglichen, weil alle nötigen Verbindunsparameter aus der Konfiguration gelesen werden können.

Der Public Key des neu generierten SSH-Schlüsselpaars wird nun an der StorageBox registriert:

cat ~/.ssh/id_ed25519.pub >> /mnt/storagebox/.ssh/authorized_keys

Für die Backups dieses Hosts wird ein neues Verzeichnis angelegt, welches das Backuparchiv enthalten soll:

mkdir /mnt/storagebox/host1

Die StorageBox kann nun wieder unmounted werden:

fusermount -u /mnt/storagebox

Backupscript erstellen

Das Backupscript soll die Informationen über den Speicherort aus Umgebungsvariablen lesen, die in einer Datei namens resticenv.sh gelesen werden. Die Definition der Umgebungsvariablen ließen sich zwar auch direkt in dem Backupscript definieren, doch die getrennte Definitionsdatei ermöglicht einen bequemeren Umgang mit Restic, falls einmal manuelle Eingriffe oder ein Restore nötig sein sollten.

resticenv.sh

#!/bin/bash
export RESTIC_REPOSITORY="sftp:u123456.your-storagebox.de:host1"
export RESTIC_PASSWORD="meinbackuparchivpassword"

Ein Backupscript backup.sh für Restic könnte beispielsweise so aussehen:

#!/bin/bash
### Restic Passwort und Speicherort einlesen
source resticenv.sh
### Restic ausführen
restic backup \
/var/www \
/home \
/etc \
/root

Bevor Restic / backup.sh erstmalig ausgeführt werden kann, muss das Backuparchiv in der StorageBox initialisiert werden. Dazu werden die Verbindungsparameter zum Archiv via source eingelesen und ein restic init ausgeführt:

source resticenv.sh
restic init

Das Restic-Archiv ist nun einsatzbereit und backup.sh kann regelmäßig ausgeführt werden.

Der Yubikey im Praxiseinsatz

thomas.leister@mailbox.org (Thomas Leister) — Wed, 01 Aug 2018 15:47:00 +0200

Seit ein paar Jahren besitze ich einen Yubikey Neo - einen USB- und NFC-kompatiblen Hardware Security Token, den ich in Kombination mit regulären Passwörtern zum Schutz von Zugangsdaten und Account einsetze. In einem früheren Beitrag habe ich bereits die verschiedenen Betriebsmodi des Yubikeys beschrieben. In diesem Beitrag will ich einen kleinen Einblick geben, wie ich mit dem Yubikey arbeite und wofür ich ihn einsetze.

Einsatzzwecke

In der letzten Jahren haben sich die Einsatzmöglichkeiten für Yubikeys im speziellen und Hardwaretokens im allgemeinen etwas verbessert. Während Zwei-Faktor-Authentifizierung vor allem im Consumer-Bereich so gut wie gar nicht zu finden war, kann man sich bei größeren Softwarekonzernen und einigen Security-Tools mittlerweile sicher anmelden.

Absicherung Logins

Mit U2F

U2F ist vor allem für das Web entwickelt. Die Verbreitung lässt zwar immer noch zu Wünschen übrig (man sagt, die Implementierung sei wohl recht komplex), aber ein paar der von mir genutzten Services unterstützen das moderne, einfach zu nutzende Verfahren bereits. Dazu gehört neben GitHub und Google auch die frei verfügbare Git-Hostingsoftware “Gitea”.

Mit TOTP

Der von mir am meisten eingesetzte Mechanismus ist TOTP: Einfach deshalb, weil er von viel mehr Diensten unterstützt wird, als das neuere U2F. Zu den von mir genutzten Anbietern gehören core-networks.de, Hetzner Online, bitcoin.de, servercow.de und Mastodon. Auch Google und GitHub habe ich zusätzlich über TOTP abgesichert - wer weiß schon, wann ich das nächste mal vor einem Rechner sitze, der kein U2F versteht … ;-)

Absicherung Passwortdatenbank

Die Absicherung meines Passwortsafes geschieht über den Challenge-Response-Mechanismus des Yubikeys. Über USB oder NFC wird eine sog. “Challenge” an den Key übertragen. Der Key trägt ein Secret in sich, und ist damit in der Lage, die Challenge zu beantworten und das korrekte Ergebnis zurückzusenden.

Unter Linux nutze ich den Yubikey-kompatiblen Passwortmanager KeePassXC. Er ist eine Neuimplementierung von KeePass und verfügt im Vergleich zu seinem Vorgänger über einige erweiterte Funktionen. Meine vorherige KeePassX-Datenbank konnte ich in KeePassXC öffnen und einen neuen Masterschlüssel festlegen: Eine Kombination aus Passwort und Challenge-Reponse-Verfahren mit dem Yubikey. Die Einrichtung ist selberklärend.

Damit ich auch unterwegs Zugriff auf wichtige Zugangsdaten habe, nutze ich auf meinem Android-Smartphone die App “Keepass2Android”. Sie unterstützt ebenfalls das Challenge-Reponse-Verfahren. In der neuesten Beta-Version (Stand Juli 2018) auch über NFC mit dem Yubikey. Erwähnenswert bzgl. der Einrichtung ist, dass die Schlüsselableitung mittels Argon2-Verfahren durchgeführt werden muss. Die Einstellung kann in der KeePassXC-Anwendung in den Verschlüsselungseinstellungen der Datenbank festgelegt werden. Wird ein anderer Algorithmus genutzt, ist KeePass2Android nicht in der Lage, mittels Yubikey/NFC zu entschlüsseln.

KeePassXC Screenshot

Ein Backup des Yubikeys erstellen

Da eine der wichtigsten Eingenschaften eines Hardware Security Tokens ist, nicht kopierbar zu sein, muss man ein paar Umwege gehen, wenn man bei Verlust ein weiteres Exemplar in der Hinterhand haben will.

Bei U2F und TOTP gilt: Man registriert sich einfach mit beiden Keys. Bei U2f ist das einfacher, weil man beim Anbieter einfach einen weiteren Key hinterlegt. Bei TOTP meistens etwas aufwändiger, denn normalerweise wird hier nur ein Secret einmalig herausgegeben und die Einrichtung eines weiteren Geräts wird nicht unterstützt. Das bedeutet, man muss wie folgt vorgehen:

Bei dem betreffenden Service einloggen.
Evtl. vorhandene 2-Faktor-Authentifizierung deaktivieren
2FA neu einrichten: Secret als Zeichenkette oder QR-Code auf beiden Keys simultan einrichten

Was die Challenge-Response-Funktion angeht, ist der Prozess je nach aktueller Nutzung mehr oder weniger aufwendig. Die schlechte Nachricht vorweg: Wer bereits einen Yubikey mit Challenge Response im Einsatz hat, muss den Mechanismus zuvor überall deaktivieren - zumindest gilt das für die meisten Anwendungen, da sie nur einen Key unterstützen.

Damit man beide Keys nutzen kann, muss das interne Secret bei beiden Keys nämlich dasselbe sein. Nun hat man natürlich nicht die Möglichkeit, einfach zu kopieren - das heißt: Wir müssen ein neues Secret für beide Schlüssel setzen. (Und deshalb kann man sich mit einem evtl. vorher genutzten Key nicht mehr einloggen!)

Das Yubikey Personalization Tool unterstützt die Einrichtung ein und desselben Secrets auf mehreren Schlüsseln. Eine Anleitung gibt es hier: https://www.yubico.com/wp-content/uploads/2016/06/YubiKey_Identical_Credentials_ConfigGuide_en.pdf

Sobald auf beiden Keys dasselbe Secret vorhanden ist, kann einer der Keys wieder mit allen Anwendungen verknüpft werden, die mit dem Challenge-Response-Verfahren arbeiten. Der zweite Key wird danach ebenso funktionieren.

Fazit

Mit meinem Yubikey kann ich mittlerweile meine wichtigsten Zugänge absichern. Vor allem die Kombination von KeePassXC und dem Yubikey im Challenge-Response-Modus gefällt mir gut. Ich würde mir jedoch noch mehr Support für die U2F-Anmeldung im Web wünschen. Alle modernen Browser sind bereits kompatibel - jetzt liegt es nur noch an den Web Services, U2F in ihren Loginsystem zu verankern.

Mein Mini Backup NAS mit Rock64 Single Board Computer

thomas.leister@mailbox.org (Thomas Leister) — Thu, 19 Jul 2018 13:57:00 +0200

Nach meinem Umzug nach Passau habe ich leider nicht mehr die schnelle Internetverbindung, die ich ich vorher hatte. Das betrifft vor allem den Uplink. Ärgerlich, wenn das früher genutzte NAS im Elternhaus steht, und die Bandbreite beim Hochladen über das Internet so gering ist, dass man Backupvorgänge immer wieder frustriert abbrechen muss, um überhaupt noch im Internet surfen zu können.

Um das Problem zu entschärfen, habe ich beschlossen, ein weiteres, aber deutlich kleineres NAS für meine Wohnung zu bauen. Es sollte keine Speichererweiterung darstellen, sondern lediglich Backups meines Laptops beherbergen. Im Folgenden will ich euch die Komponenten meines NAS und das Resultat vorstellen.

Anforderungen an das neue System waren:

Geringer Stromverbrauch
Geringe Lärmemissionen (kleine Wohnung, Nähe zum Bett)
Geringe Anschaffungskosten (immer noch Student …)
Hohe Performance (Backups sollen möglichst schnell von der Bühne gehen)
Die Möglichkeit, das System auch für andere Zwecke einsetzen zu können (DNS, VPN, …)

Hardware

Auf meiner Suche nach einer Hardware-Basi für meine Eigenbau-NAS-Lösung bin ich auf das Pine Rock64 Board gestoßen. Das kurze SBC Vergleichsvideo von ExplainingComputers zeigt verschiedene Single Board Computer im Hinblick auf ihre NAS-Tauglichkeit. Das Rock64 Board hat mir vor allem wegen des USB 3.0 Anschlusses und der Gigabit Ethernet Schnittstelle gut gefallen. Beide Schnittstellen können gleichzeitig intensiv genutzt werden, ohne dass die eine Schnittstelle die andere Ausbremst (wie es bei den meisten anderen Single Board Computern der Fall ist). Häufig hängen Ethernet und USB an einem (USB 2.0) Bus, sodass die Leistung stark reduziert wird, wenn beides genutzt wird. Vor allem bei NAS-Anwendungen ist das hinderlich, denn so kann man keine der beiden Schnittstellen voll ausschöpfen.

Beim Rock64 ist das anders: Die Schnittstellen sind an verschiedene USB-Hosts angebunden und müssen sich die Bandbreite daher nicht teilen. Ethernet und USB 3.0 können damit unabhängig voneinander voll ausgelastet werden.

Für den Datenspeicher habe ich mich für eine 1 TB SSD von Crucial entschieden. Eine SSD sollte es vor allem wegen des Strombedarfs und des Lärmpegels sein. Zudem sollte bei diesem NAS auf ein RAID zur Datenabsicherung verzichtet werden. Um dennoch ein zuverlässiges System zu erhalten, empfiehlt sich der Einsatz eines nichtmechanischen Datenspeichers. Und nicht zuletzt sorgt eine SSD natürlich für ein angenehm schnelles System. Der Flaschenhals des NAS sollte am Gigabit-Ethernet liegen - nicht am Datenspeicher.

Zusammen mit einem USB-Festplattengehäuse und einem zum Rock64 passenden Acrylglasgehäuse lässt sich ein einfaches und leistungsfähiges, aber optisch durchaus ansprechendes NAS bauen.

Teileliste und Preise

* Pine
* Pine Rock64 Board 4 GB | ~ 38,00 €
* Pine Rock64 Kühlkörper (optional) | ~ 0,40 €
* Steckernetzteil EU | ~ 6,00 €
* Acrylgehäuse Rock64 | ~ 6,80 €
* Versand aus China nach Europa | ~ 10,00 €
* Samsung EVO Plus Micro SDXC 64 GB Class 10 U3 | ~ 20,00 €
* ICY BOX Case 2,5 Zoll SATA USB 3.0 Festplattengehäuse | ~ 18,00 €
* 1000GB Crucial MX500 2.5" (CT1000MX500SSD1) | ~ 210,00 €
--------------------------------------------------------------------------------------------
Gesamtkosten: 309,20 €
(Stand: Juli 2018)

SD-Karte und Arbeitsspeicher sind höher dimensioniert als nötig, weil ich vorhabe, das Board nicht nur als NAS, sondern auch für den Betrieb anderer, kleiner Dienste zu nutzen. Wer das Rock64 Board nur als NAS einsetzen will, ist auch mit der günstigeren 1 GB-Version des Rock64 und einer kleineren SD-Karte gut beraten.

Software

Ursprünglich hatte ich vor, das NAS mit FreeBSD zu betreiben. Einerseits wegen des nativen ZFS-Supports, aber auch, um in der Praxis mehr in den Kontakt mit FreeBSD zu kommen. Leider gab es zum Zeitpunkt des Zusammenbaus noch kein FreeBSD-Image für das Rock64 Board, sodass ich mich stattdessen für die schlanke Linuxdistribution DietPi entschieden habe, die auf Debian aufbaut. Die Distribution ist speziell auf Single Board Computer getrimmt, sehr schlank und unterstützt das Rock64 Board offiziell.

Meine Entscheidung habe ich nicht bereut: Standardmäßig ist nur das nötigste Installiert. Probleme mit Treibern oder ähnlichem konnte ich bisher nicht finden.

Meine Backups mache ich übrigens mit dem Backup-Tool “Restic”. Als Zugang zum Backup-NAS genügt mir daher ein ganz normaler SSH-Zugang. Der Zugriff auf den Speicher erfolgt dann via SFTP.

Leistung

SSD

Lesen von SSD via USB 3.0:

hdparm -tT --direct /dev/sda
/dev/sda:
Timing O_DIRECT cached reads: 588 MB in 2.00 seconds = 293.31 MB/sec
Timing O_DIRECT disk reads: 992 MB in 3.00 seconds = 330.25 MB/sec

Schreiben auf die SSD via USB 3.0:

dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.80873 s, 282 MB/s

Die Datenraten fallen in Verbindung mit dem Rock64 SBC geringer aus als bei direkter Nutzung am Laptop:

Möglicherweise ist der USB-Controller des Rock64 nicht so leistungsfähig wie der meines Laptops und kann deshalb keine höhere Bandbreite erreichen. Bei der Nutzung des NAS fällt die geringere Leistung allerdings nicht ins Gewicht, da hier die Ethernet-Schnittstelle mit einer theoretischen maximalen Datenrate von 120 MB/s der limitierende Faktor ist.

Ethernet

Die Gigabit-Schnittstelle erreicht die praktisch zu erwartende Maximalleistung von ~940 MBit/s. Gemessen habe ich mittels iperf:

iperf -c 192.168.178.100 -r
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.178.100, TCP port 5001
TCP window size: 196 KByte (default)
------------------------------------------------------------
[ 5] local 192.168.178.28 port 46066 connected with 192.168.178.100 port 5001
[ ID] Interval Transfer Bandwidth
[ 5] 0.0-10.0 sec 1.09 GBytes 938 Mbits/sec
[ 4] local 192.168.178.28 port 5001 connected with 192.168.178.100 port 42658
[ 4] 0.0-10.0 sec 1.08 GBytes 923 Mbits/sec

Im Upload werden also ~ 938 MBit/s erreicht, im Download sind es ~ 923 MBit/s.

SD-Karte

Lesen:

hdparm -tT --direct /dev/mmcblk1
/dev/mmcblk1:
Timing O_DIRECT cached reads: 46 MB in 2.08 seconds = 22.17 MB/sec
Timing O_DIRECT disk reads: 68 MB in 3.04 seconds = 22.35 MB/sec

Schreiben:

dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 61.1467 s, 17.6 MB/s

Nicht nur die SSD, sondern auch die SD-Karte erreicht an Rock64 eine geringere Leistung, als an meinem Laptop. So konnte ich die SD-Karte am Laptop mit 44 MB/s lesen. Das ist schade, aber nicht weiter tragisch. Denn die Zugriffe auf die SD-Karte halten sich während des Betriebs ohnehin in Grenzen und spielen bei Backupvorgängen keine Rolle. Mit dem System lässt sich trotzdem relativ flüssig arbeiten (Softwareinstallation, Konfiguration, …).

SFTP

Die Übertragung einer großen Datei von meinem Laptop auf die NAS-SSD via SFTP lief mit ~ 67 MB/s. Nicht besonders schnell, wenn man die vorherigen Einzelmessungen von Ethernet-Schnittstelle und SSD berücksichtigt. Ein Grund für die eher mäßige Leistung könnte Overhead durch das SFTP-Protokoll und/oder die Verschlüsselung der Datenübertragung sein.

Einiger Quellen im Netz zufolge scheint SFTP tatsächlich nicht besonders gut für schnelle Dateiübertragungen zu sein. Zum einen wegen der Verschlüsselung/Entschlüsselung, zum anderen wegen seines Designs:

Ich habe verschiedene Cipher für die Datenübertragung ausprobiert - keiner davon brachte eine Verbesserung im Vergleich zum Standardcipher AES256-GCM.

Samba

Schreiben einer Datei auf ein Samba Share: ~ 56 MB/s
Lesen eines Samba Shares: ~ 64 MB/s

Warum die Leistung auch im Samba-Betrieb vergleichsweise gering ist, konnte ich bisher nicht herausfinden. Der YouTube-User ExplainingComputers konnte (unter Windows) beispielsweise mit etwa 93 MB/s mittels Samba Share auf eine SSD schreiben.

Möglicherweise kann eine höhere Leistung durch Optimierung der Konfiguration erreicht werden.

NFS v4

Die Datenübertragung mittels NFS (Version 4) war mit Abstand die schnellste: Die Gigabit-Anbindung konnte hiermit voll ausgenutzt werden. Datenraten von ~ 118 MB/s wurden so erreicht.

Zu beachten ist allerdings, dass die Datenübertragung hier (wie auch beim Samba-Share) standardmäßig unverschlüsselt abläuft. Wer die Verschlüsselung über die Kerberos-Erweiterung aktiviert, muss auch hier mit drastischen Performanceeinbußen rechnen NFS mit Kerberos: Vergleichstest

Fazit

Ich bin mit meinem neuen NAS insgesamt zufrieden. Die Einzelleistungen der Komponenten sind für meine Zwecke für sich genommen völlig ausreichend. Schade zwar, dass SD-Karte und SSD nicht so schnell arbeiten, wie sie es an einem ausgewachsenen x86-Laptop tun, aber darüber kann ich hinwegsehen. Im Betrieb fällt das kaum ins Gewicht.

Etwas ärgerlich ist, dass ich mit dem eigentlich fokussierten SFTP nicht so schnell auf den Speicher zugreifen kann, wie ich mir das ausgemalt hatte. 67 MB/s sind zwar schon ganz gut, aber dennoch würde ich ich die Ethernet-Verbindung gerne ganz ausreizen. Das gelingt mir aktuell nur mit einer ungesicherten NFS-Verbindung. Weil ich meine Daten nur ungern unverschlüsselt (auch über eigene) Netze übertrage, werde ich mich erst einmal mit der eingeschränkten Leistung abfinden.

In nächster Zeit werde ich nach Möglichkeiten suchen, die Leistung bei SFTP-Übertragungen zu erhöhen. Vielleicht finde ich auch eine andere Art der schnellen und sicheren Datenübertragung - oder ich entscheide mich doch für ungesichertes NFS in Kombination mit einer Ende-zu-Ende Absicherung meiner Daten. Sollte ich zu einem Ergebnis kommen, das mit gefällt, wird das in diesem Beitrag natürlich ergänzt.

Ansonsten peile ich noch an, die Daten auf dem NAS auf mein älteres, größeres NAS zu replizieren. Idealerweise natürlich Nachts, wenn ich die Internetverbindung selbst nicht nutze. So hätte ich zum einen einen schnellen lokalen (Zwischen?) Speicher, und müsste zum anderen nicht auf Geo-Replizierung verzichten.

TeamViewer für das CLI: Terminal-Sessions freigeben

thomas.leister@mailbox.org (Thomas Leister) — Tue, 26 Dec 2017 16:19:00 +0100

Ein Kunde wollte mir kürzlich bei meiner Arbeit über die Schulter schauen, um einen Serverfehler und dessen Behebung live nachvollziehen zu können. Mein erster Gedanke ging in Richtung TeamViewer und Co. Ich könnte doch meinen Desktop einfach für ihn freigeben - oder gibt es eine bessere Alternative? Bei meiner Recherche habe ich ein paar Wege gefunden, meine Kommandozeile ohne TeamViewer freizugeben.

Freigabe mit Screen

GNU Screen dürfte vielen Linux-Administratoren bekannt sein. Es wird häufig genutzt, um länger andauernde Prozesse im Terminal außerhalb einer laufenden SSH-Sitzung weiter laufen zu lassen. Gewollte oder ungewollte Verbindungsabbrüche beenden die Ausführung eines CLI-Tools im Vordergrund nicht, denn die Sitzung ist vom SSH-Login entkoppelt. Der Benutzer kann sich jederzeit wieder zu seiner virtuellen Konsolensitzung verbinden oder sich von ihr trennen.

Aber auch zum Teilen von Sitzungen eignet sich Screen. Ich gehe davon aus, dass beide Teilnehmer sich mit demselben Benutzer via SSH zum Server verbinden. Nun soll eine Screen-Terminalsitzung erstellt und mit dem zweiten Teilnehmer geteilt werden:

User 1 erstellt eine neue Screen-Sitzung:

screen -S sharedsession

User 2 verbindet sich zu dieser Sitzung:

screen -x sharedsession

Beide Benutzer können sich via CTRL-A + D jederzeit wieder von der Session loslösen. Ein “exit” beendet die Sitzung auf beiden Seiten. Wird die SSH-Verbindung zum Server über verschiedene Benutzer hergestellt, müssen weitere Einstellunen gesetzt werden. Das Vorgehen ist am Ende dieser Seite erklärt: http://wiki.networksecuritytoolkit.org/index.php/HowTo_Share_A_Terminal_Session_Using_Screen

Leider unterstützt Screen keinen Readonly-Modus - Beide Teilnehmer sind gleichberechtigt und können Kommandos ausführen.

Freigabe mit Tmux

Auch mit Tmux ist eine Freigabe schnell eingerichtet:

User 1 erstellt eine tmux-Sitzung:

tmux new-session -s sharedsession

User 2 schaltet sich auf:

 tmux attach-session -t sharedsession

Wieder sind beide Benutzer gleichberechtigt. Benutzer 2 kann sich allerdings auch im “Read only”-Modus zur Sitzung verbinden. Er kann dann keine Eingaben vornehmen:

tmux attach-session -r -t sharedsession

Via CTRL-B + D kann sich jeder der Teilnehmer von der Sitzung loslösen. Ein “exit” beendet die Sitzung.

Freigabe via SSH und Webinterface mit Tmate

Der meiner Meinung nach schönste Weg zur Freigabe führt über das Tool “tmate”. Es ist eine Ableitung von tmux und erlaubt u.A. die Freigabe über eine HTML5-Webseite: Der Eingeladene bekommt einen Link, über den er entweder aktiv an der Sitzung teilnehmen kann oder nur passiv zusehen kann. Neben der Website kann auch via SSH zugegriffen werden. Nachteil: tmate ist nicht in allen Standardrepositories der gängigen Linuxdistributionen enthalten. Notfalls ist das Tool aber auch schnell selbst kompiliert. Die notwendigen Schritte sind auf der tmate-Website dokumentiert: https://tmate.io/

User 1 erstellt eine tmate-Sitzung (entweder lokal oder auf dem Server):

tmate

User 1 lässt sich die Links zur Sitzung ausgeben und gibt den gewünschten Link weiter

tmate show-messages

User 2 öffnet den Link zur Website oder verbindet sich via SSH.

“Read only”-Modus, Normaler modus, HTML5-Website und SSH-Zugriff sind beliebig kombinierbar. So sollte für jeden Anwendungszweck etwas dabei sein.

Fedora 27: ED25519 OpenSSH Keys nach Benutzung entsperrt lassen

thomas.leister@mailbox.org (Thomas Leister) — Sun, 17 Dec 2017 12:12:00 +0100

Leider kommt der Gnome Keyring nach wie vor nicht mit ED25519-SSH-Schüsseln zurecht. Das heißt: Standardmäßig muss bei jeder Verwendung eines SSH-Keys das dazugehörige Passwort erneut eingegeben werden. Mit dem Tool “Keychain” kann der Prozess vereinfacht werden: Auf meinem Fedora-Rechner ist die Eingabe des Passworts für einen Schlüssel von nun an nur noch bei der ersten Verwendung notwendig.

Installation des “Keychain” Tools:

sudo dnf install keychain

Wird Keychain gestartet, sucht es nach einer bereits laufenden ssh-agent-Instanz, welche SSH-Keys in einem entsperrten Zustand zwischenspeichern kann. Existiert eine solche Instanz, verknüpft es die laufende Shell-Instanz mit diesem Agent. Läuft kein solcher Agent-Prozess, wird einer gestartet. Damit nicht bei jedem Start eines Shell-Fensters (z.B. Gnome Terminal) das Startkommando für Keychain manuell eingegeben werden muss, kann in der ~/.bashrc Datei ein Autostart-Eintrag angelegt werden:

eval $(keychain --eval -Q --quiet)

Da ich nicht die Bash verwende, sondern die Zsh-Shell, habe ich stattdessen folgende Zeile zu meiner Zsh-Konfiguration ~/.zshrc hinzugefügt:

### Start Keychain
eval `keychain -q --eval --quiet`

In der SSH-Konfiguration unter ~/.ssh/config habe ich eine weitere Zeile hinzugefügt:

AddKeysToAgent yes

Diese Zeile konfiguriert SSH so, dass einmal verwendete Schlüssel an den SSH-Agent übermittelt werden, sodass sie dort zwischengespeichert werden können.

Übrigens: Üblicherweise werden dem Keychain-Kommando schon beim Start die zu entsperrenden Keys mitgegeben:

eval $(keychain --eval -Q --quiet ~/.ssh/id_ed25519)

In diesem Fall ist die Konfiguration von SSH (zur Übermittlung des Keys) nicht notwendig. Allerdings hat diese Variante den unangenehmen Nebeneffekt, dass man beim Öffnen eines Terminal-Fensters sofort mit der Entsperrung eines Keys belästigt wird - auch, wenn man erst einmal gar nicht vor hat, einen der hinterlegten Keys zu nutzen. Daher übergebe ich Keychain zunächst keine Schlüssel. Keychain hat dann nur die Aufgabe, einen zentralen SSH-Agent mit allen Shell-Instanzen zu verknüpfen. Das Hinzufügen von Keys zum Agent geschieht bei mir über die zusätzliche SSH-Konfiguration.

Um die neuen Einstellungen zu übernehmen, müssen alle Terminal-Fenster bzw. Shell-Instanzen geschlossen und neu geöffnet werden. Beim Start sollte Keychain sichergestellt haben, dass ein SSH Agent läuft und mit der jeweiligen Shell verknüpft ist. Wird nun beispielsweise eine SSH-Anmeldung an einem fremden Rechner durchgeführt, wird nach dem Passwort für den Schlüssel gefragt. Nach Beendigung der Session und einem weiteren SSH-Befehl muss das Passwort nicht mehr eingegeben werden. Das gilt auch für alle weiteren, geöffneten Shell-Instanzen.

Wer das Setup etwas sicherer gestalten möchte, kann Keychain anweisen, den ssh-agent-Prozess mit einer Timeout-Flag zu starten. Zwischengespeicherte Keys werden dann nur für einen beschränkten Zeitraum im Speicher belassen (timeout in Minuten):

eval $(keychain --eval -Q --quiet --timeout 30)

Nach Ablauf des Timeouts ist eine erneute Passworteingabe erforderlich. Eine manuelle Sperrung aller Keys kann bei Bedarf mit folgendem Kommandos durchgeführt werden:

keychain --clear

Das hier vorgestellte Setup ermöglicht mir einen ähnlich bequemen Umgang, wie er mir mit meinen RSA-Schlüsseln über den Gnome-Schlüsselmanager möglich war. Die Verwendung von technisch überlegenen ED25519-Schlüsseln bedeutet nun keine Beeinträchtigung meines Workflows mehr. Das ständige Eintippen von langen, komplexen Passwörtern hat damit ein Ende.

Einen zentralen Mailserver (Mail-Gateway) mit weiteren Hosts nutzen

thomas.leister@mailbox.org (Thomas Leister) — Tue, 12 Sep 2017 14:30:00 +0200

Wer bereits ein Mail-System für den Versand und Empfang von E-Mails aufgesetzt hat, weiß, dass das je nach Funktionsumfang viel Arbeit sein kann. Wenn nicht nur ein Host E-Mails verschicken soll, sondern mehrere, kann es sich lohnen, einen zentralen Mailserver als “Mail-Gateway” zu nutzen. Das bedeutet: Für den Versand von E-Mails in das Internet und den Empfang aus dem Internet ist nur dieser eine Mailserver zuständig. Alle weiteren Hosts (“externe Hosts”) benötigen keine aufwendige Mailserver-Konfiguration, sondern kommen mit einer Minimalkonfiguration aus, welche es ihnen erlaubt, beim Versand auf das Gateway zurückzugreifen. DKIM, SPF und weitere Versand-spezifische Merkmale müssen dann nur auf dem Gateway eingerichtet und gewartet werden.

“Gateway”: Der Server, auf dem das Mailsystem eingerichtet ist.
Host" / “externer Host”: Ein Server, der für den Mailversand den Mailserver nutzen soll.

Im folgenden setze ich voraus, dass das Mail-Gateway nach meiner Mailserver-Anleitung aufgesetzt ist. Prinzipiell funktioniert es aber ähnlich auch mit anderen Gateways

Postfix-Grundkonfiguration auf dem externen Host

Externen Mailempfang auf den Hosts abschalten

Ẁenn ein Host nur für den Versand verwendet wird, kann der smtpd-Teil von Postfix abgeschaltet werden. In der Datei /etc/postfix/master.cf werden smtpd und ggf. submission-Teil einfach auskommentiert:

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
#smtp inet n - - - - smtpd
#smtp inet n - - - 1 postscreen
#smtpd pass - - - - - smtpd
#dnsblog unix - - - - 0 dnsblog
#tlsproxy unix - - - - 0 tlsproxy
#submission inet n - - - - smtpd
# -o syslog_name=postfix/submission
# -o smtpd_tls_security_level=encrypt
# -o smtpd_sasl_auth_enable=yes
# -o smtpd_client_restrictions=permit_sasl_authenticated,reject
# -o milter_macro_daemon_name=ORIGINATING
#smtps inet n - - - - smtpd
# -o syslog_name=postfix/smtps
# -o smtpd_tls_wrappermode=yes
# -o smtpd_sasl_auth_enable=yes
# -o smtpd_client_restrictions=permit_sasl_authenticated,reject
# -o milter_macro_daemon_name=ORIGINATING

Eine main.cf nur für den Nachrichtenversand

In der /etc/postfix/main.cf müssen nur wenige Einstellungen festgelegt werden. Diese werden je nach Art des Setups (im Folgenden) erweitert.

myhostname = host1.mydomain.tld
inet_protocols = all
inet_interfaces = 127.0.0.1, 10.8.0.1
##
## Mail-Queue Einstellungen
##
maximal_queue_lifetime = 1h
bounce_queue_lifetime = 1h
maximal_backoff_time = 15m
minimal_backoff_time = 5m
queue_run_delay = 5m
##
## TLS Einstellungen
###
tls_ssl_options = NO_COMPRESSION
tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA
### Ausgehende Verbindungen (SMTP Client)
smtp_tls_security_level = dane
smtp_dns_support_level = dnssec
smtp_host_lookup = dns, native
smtp_tls_note_starttls_offer = yes
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_ciphers=high
smtp_tls_CAfile =/etc/ssl/certs/ca-certificates.crt
smtp_tls_loglevel = 0

(Bitte anpassen!)

Fall 1: Externer Host mit statischer IP-Adresse

Hosts, die über eine statische IP-Adresse (also eine immer gleich bleibende Adresse) erreichbar sind, kann sehr einfach der Zugriff auf das Gateway erlaubt werden. Dazu wird z.B. Host1 mit der IP-Adresse 10.8.0.1 in der Konfiguration des Gateways in mynetworks (main.cf) aufgenommen, z.B. so:

mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
10.8.0.1/32

Anwenden der neuen Einstellungen auf dem Mail-Gateway mail.mysystems.tld:

systemctl reload postfix

Auf dem externen Host host1.mydomain.tld wird Postfix via relayhost angewiesen, sämtliche Mails, die nicht lokal zugestellt werden können, an das Gateway weiterzureichen. Die Datei /etc/postfix/main.cf auf dem Host wird dazu um folgende Zeilen erweitert:

##
## Alle E-Mails an nicht-lokale Empfänger an das Gateway weiterleiten
##
relayhost = mail.mysystems.tld

Anwenden der Einstellungen auf dem externen Host host1.mydomain.tld

systemctl reload postfix

Fall 2: Externer Host mit dynamischer IP-Adresse (z.B. Homeserver)

Wenn ein Host über keine statische IP-Adresse verfügt, wie es z.B. bei den meisten Homeservern der Fall ist, muss zu einem etwas komplizierteren Setup gegriffen werden. In diesem Fall kann der Host nicht über die IP-Adresse autorisiert werden, sodass wir auf die normale SMTP-Authentifizierung zurückgreifen. Letztendlich ist die Postfix-Instanz auf dem Host für das Gateway also nichts weiteres als ein ganz normaler E-Mail-Client. Daher muss das Gateway auch über den Submission Port 587 angesprochen werden - nicht über Port 25!. Fügt die folgende Zeile am Host in der /etc/postfix/main.cf an:

relayhost = [mail.mysystems.tld]:587

Für die Authentifizierung wird außerdem der folgende Block unten angefügt:

##
## Authentifizierung am Relayhost
##
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/relay_passwd
smtp_sasl_security_options = noanonymous

Die Postfix-Instanz auf dem Host meldet sich wie ein normaler MUA (Mail user Agent) an, und muss daher auch ein entsprechendes Mailkonto auf dem Mail-Gateway besitzen, z.B. host3@mysystems.tld. Die dazugehörigen Zugangsdaten werden in die Datei /etc/postfix/relay_passwd eingetragen:

[mail.mysystems.tld]:587 host3@mysystems.tld:meinpasswort

Via

postmap /etc/postfix/relay_passwd

wird eine Datenbank-Datei erzeugt, die von Postfix gelesen werden kann. Bei jeder Änderung an relay_passwd muss dieses Kommando erneut ausgeführt werden.

Eine Besonderheit gibt es bei dieser Art des Setups noch: Da Postfix einen normalen Benutzer-Account für die Verbindung zum Gateway nutzt, ist er auch den Beschränkungen unterworfen, die für solche Accounts gelten. So dürfen Benutzer gemäß meines Mailserver-Setups nur E-Mails in ihrem eigenen Namen versenden. Damit soll Adressfälschung bei ausgehenden E-Mails verhindert werden. Der Host dürfte also nur E-Mails mit dem Absender host3@mysystems.tld erzeugen. Alles andere würde vom Gateway blockiert werden. Nun senden einige Tools wie z.B. mdadm aber standardmäßig im Namen root@host3.mydomain.tld - der Versand würde scheitern.

Die Lösung für das Problem ist ein Neu-Schreiben des “Envelope-From”: E-Mails, die vom Host ausgehen, werden so umgeschrieben, dass deren Absender immer host3@mysystems.tld lautet. Damit wird das Problem umgangen. Zum Umschreiben wird die Einstellung sender_canonical_maps genutzt. Fügt das folgende Snippet unten an die main.cf an:

###
### Adressen von Absendern, z.B. root@host3.mydomain.tld müssen nach host3@mysystems.tld umgeschrieben werden
### Für außenstehende Systeme darf es nur host3@mysystems.tld als Absender geben.
###
sender_canonical_maps = hash:/etc/postfix/rewrite_from

… und erzeugt eine neue Datei /etc/postfix/rewrite_from mit folgendem Inhalt:

@host3.mydomain.tld host3@mysystems.tld

Auch diese Datei wird via postmap in eine für Postfix lesbare Datenbank umgewandelt.

postmap /etc/postfix/rewrite_from

Anwenden der Einstellungen:

systemctl reload postfix

Lokale Mailzustellung auf externen Hosts verhindern und Mails weiterleiten

Standardmäßig werden E-Mails, die beispielsweise an den lokalen “root”-User eines externen Hosts gehen, nicht über das Gateway geschickt. Benachrichtigungsmails bzgl. RAID-Status, APT-Status und Mails von weiteren Softwarepaketen bleiben dann lokal in /var/mail/root liegen und geraten in Vergessenheit. Durch ein Umschreiben des Empfängers von selbst erzeugten Mails können diese Systemmails aber abgegriffen und an eine beliebige, andere Mailadresse weitergeleitet werden. Dazu wird in /etc/postfix/main.cf auf dem jeweiligen Host folgendes unten angefügt:

###
### Lokale Empfänger *@host1 (z.B. "root") umschreiben
### damit Mails nicht in /var/mail/root abgelegt werden, sondern an beliebigen Empfänger weitergeleitet werden.
###
recipient_canonical_maps = hash:/etc/postfix/rewrite_local_to

Die zugehörige Datei /etc/postfix/rewrite_local_to wird mit folgendem Inhalt angelegt:

@host1.mydomain.tld postmaster@mysystems.tld

Damit würden sämtliche Mails an lokale Nutzer des Hosts an postmaster@mysystems.tld weitergeleitet werden. Wer das Umschreiben des Empfängers beschränken will, kann statt @host1.mydomain.tld auch vollständige Adressen wie z.B. root@host1.mydomain.tld angeben.

Nach dieser Konfigurationsänderung ist es notwendig, die passende Datenbankdatei für Postfix zu erzeugen und den Dienst neu zu starten:

postmap /etc/postfix/rewrite_local_to
systemctl reload postfix

Das Postmap-Kommando muss nach jeder Änderung in der Datei rewrite_local_to wiederholt werden!

Setup testen

Auf den Hosts kann das Verhalten von Postfix überprüft werden, indem eine kleine Testmail verschickt wird:

echo "Testmail an eine beliebige E-Mail-Adresse" | mail -s "Testmail" postmaster@mysystems.tld

Ob auch E-Mails an den lokalen “root” User eines Hosts erfolgreich eingesammelt und weitergeleitet werden, kann hiermit überprüft werden:

echo "Testmail an den lokalen root-User" | mail -s "Testmail" root

Systemd: Service-Start von Netzwerk-Interface abhängig machen

thomas.leister@mailbox.org (Thomas Leister) — Mon, 11 Sep 2017 12:46:00 +0200

In meinem letzten Beitrag habe ich mein PeerVPN-Setup zur Realisierung meines Wartungsnetzes vorgestellt. Wenige Stunden später musste ich feststellen, dass ich bei meinem Setup etwas wichtiges nicht bedacht hatte: Bei einem Server-Neustart versuchen die Dienste, die nur über das Wartungsnetze 10.8.1.0/24 erreichbar sein sollen, sich an das srvnet0-Interface zu binden. Das schlägt allerdings fehl, denn der Docker-Container mit dem PeerVPN-Node startet erst wesentlich später, und die srvnet0-Schnittstelle existiert bis zu diesem Zeitpunkt noch nicht. Das wird mit Fehlermeldungen und nicht verfügbaren Diensten bestraft. Die Lösung ist, diese Dienste warten zu lassen, bis srvnet0 verfügbar ist.

Ein neues Systemd-Target einführen

Da der Zeitpunkt der srvnet0-Verfügbarkeit ein wichtiger Anker für weitere Abhängigkeiten ist, habe ich mich entschieden, auf meinen Systemen ein neues Systemd-Target /etc/systemd/system/srvnet0.target einzuführen:

[Unit]
Description=target is active if srvnet0 interface is available
Requires=sys-subsystem-net-devices-srvnet0.device
After=sys-subsystem-net-devices-srvnet0.device

Sobald die srvnet0-Schnittstelle verfügbar ist, wechselt der Status des Targets auf “active”, und alle vom Target abhängigen Dienste werden nun ebenfalls gestartet. Der Docker-Container mit PeerVPN wird bereits durch den automatisch startenden Docker-Daemon gestartet, denn als “restart”-Policy wurde für diesen Container “always” angegeben. Darum müssen wir uns also nicht kümmern.

Weitere Dienste vom Target abhängig machen

Nun, da das neue Target definiert ist, und den Zeitpunkt markiert, an dem die VPN-Schnittstelle verfügbar ist, muss dieses nur noch in die Service-Definitionen als Requirement aufgenommen werden:

After=srvnet0.target
Requires=srvnet0.target

Es ist allerdings ratsam, diese Definition nicht in bereits bestehenden Unit-Files zu ergänzen, sondern stattdessen eine weitere Konfigurationsdatei zu erzeugen, welche ein bestehendes Unit-File automatisch ergänzt. Soll beispielsweise der Unbound-Resolver (Service: unbound.service) auf die srvnet0-Schnittstelle warten, so wird ein Verzeichnis /etc/systemd/system/unbound.service.d/ angelegt, und darin eine Datei unbound.conf. Diese enthält folgenden Inhalt:

[Unit]
After=srvnet0.target
Requires=srvnet0.target

Systemd führt alle Unit-Files inkl. Ergänzungsdateien dann automatisch zusammen. Konflikte bei Paket-Upgrades durch manuell veränderte Unit-Files werden somit verhindert und Anpassungen bleiben von den Standardkonfigurationen sauber getrennt.

Die neue Systemd-Konfiguration wird nun neu geladen:

systemctl daemon-reload

Nach einem Reboot kann überprüft werden, ob Target und abhängiger Service erfolgreich gestartet wurden:

systemctl status srvnet0.target
systemctl status unbound.service

Beide Kommandos sollten in grüner Farbe “active” zeigen.

Die srvnet0-Schnittstelle ist übrigens schon verfügbar, bevor Traffic durch das VPN geschickt werden kann. Bis die Kommunikation zwischen den Nodes funktioniert, können noch ein paar Sekunden vergehen. Anwendungen können jedoch schon vorher Ports auf dieser Schnittstelle belegen.

Weitere Services können vom Target abhängig gemacht werden, indem für sie ebenfalls ein neues, passend benanntes Verzeichnis mit der oben stehenden Konfiguration angelegt wird. (Neuladen der Systemd-Konfiguration nicht vergessen!)

Ein Wartungsnetz für meine Server-Infrastruktur mit PeerVPN und Docker

thomas.leister@mailbox.org (Thomas Leister) — Tue, 05 Sep 2017 14:14:00 +0200

In meinem Beitrag “Dezentrales HA Servercluster-VPN mit PeerVPN” habe ich euch PeerVPN vorgestellt - einen kleinen Peer-to-Peer VPN-Server, der sich wunderbar eignet, um seine Hosts miteinander zu vernetzen. Ich betreibe selbst mehrere Server an verschiedenen Standorten, die direkt miteinander Daten austauschen. So kommuniziert beispielsweise jeder Host mit einem zentralen Munin-Server, um Statusupdates zu senden. Auch Icinga-Daemons laufen auf den Hosts und prüfen verschiedene lokale Dienste. Das Ergebnis wird an das Icinga-Backend geschickt.

All diese Kommunikation soll für die Öffentlichkeit nicht einsehbar sein, d.h.:

Die Existenz von Wartungs- und Verwaltungsdiensten soll verborgen werden
Die Verbindung soll verschlüsselt werden: Internet und Hoster kann im Zweifel nicht getraut werden
Nur autorisierte Personen oder Maschinen sollen Zugriff auf bestimmte Dienste haben (z.B. Admin, Munin-Frontend)

Ziel ist also ein “Wartungsnetz”, welches nur dem Austausch der Hosts untereinander und dem Administrator dienen soll. Dienste wie Munin-Clients, Icinga-Clients, Docker-Daemons und sonstiges werden fest an die IP-Adresse aus dem Wartungsnetz gebunden und sind damit nicht mehr über die öffentlichen IP-Adressen des jeweiligen Hosts erreichbar. Das bringt drei Vorteile mit sich:

Ein aufgeräumtes Setup: Öffentliches kommt ans Internet, Privates in ein eigenes Netz.
Sicherheit:
- Sicherheitskritische Dienste und Dienste, die nicht für die Öffentlichkeit bestimmt sind, sind aus dem Internet nicht erreichbar.
- Es gibt Client-Server-Software, die nicht für den Betrieb im Internet ausgelegt ist, sondern nur für die Verwendung innerhalb eines Rechenzentrums (z.B. in dedizierten, lokalen Netzen). Auf Verschlüsselung und Authentifizierung wird hier oftmals verzichtet. Diese Software kann in einem solchen Wartungsnetz trotzdem guten Gewissens genutzt werden.
Komfort: Software via MySQL, Redis und weitere beherrschen zwar oft die Absicherung der Verbindung in einem Client-Server / Cluster -Setup, doch das Einbinden neuer Nodes ist nicht immer bequem. So beherrscht beispielsweise auch Munin sichere Verbindungen via TLS - dafür muss dann aber eine X.509-CA aufgebaut und gepflegt werden. Das schließt dann auch das umständliche Hantieren mit Zertifikaten ein. In einem dedizierten, sicheren Host-Netz kann auf die Munin-eigene Authentifizierung verzichtet werden.

Heute habe ich die vollständige Vernetzung all meiner Hosts in ein eigenes Wartungsnetz (bzw. virtuelles “lokales” Netz) in Angriff genommen. Sofort war klar, dass ich das Netz mit PeerVPN realisieren wollte, um einen Single Point of Failure zu vermeiden. Bei Installieren der Software auf dem ersten Server ist mir jedoch folgendes aufgefallen:

PeerVPN ist nicht kompatibel mit OpenSSL 1.1, welches von allen Hosts verwendet wird. Das Problem lässt sich lösen, indem PeerVPN statisch mit LibreSSL gelinkt wird. Dann bekommen die LibreSSL-Bibliotheken allerdings keine automatischen Updates durch das Betriebssystem. Heißt: Updates für LibreSSL müsste ich dann manuell verfolgen, und auf jedem der Hosts bei Bedarf PeerVPN neu linken.
Die Installation von PeerVPN ist nicht besonders zeitintensiv, aber die Einrichtung auf mehreren Hosts artet dann doch in Arbeit aus: Quellcode herunterladen, LibreSSL herunterladen, PeerVPN kompilieren und linken, im System integrieren, und einen Systemd-Service erstellen.

Das muss doch auch bequemer gehen. Und vor allem die Sache mit den Updates wollte ich eleganter gelöst haben.

Eine komfortable Lösung: PeerVPN im Docker-Container

Wenn man eine einzelne Anwendung als Baustein unabhängig vom Hostsystem ausrollen will, bieten sich Linux-Container an. Ich musste sofort an einen Docker-Container denken, den ich auf jedem meiner Hosts starten kann. PeerVPN sollte im Docker-Container laufen und mittels Host-Networking allen anderen Diensten auf demselben Host den Zugriff auf das Wartungsnetz ermöglichen. Glücklicherweise hat sich Markus Juenemann bereits Gedanken zu PeerVPN unter Docker gemacht, sodass ich seine Arbeit aufgreifen konnte. Ein paar kleine Änderungen habe ich schließlich in einen Fork des Projekts eingebracht: https://github.com/ThomasLeister/docker-alpine-peervpn (die meisten Änderungen sind inzwischen via Pull Request zurück in das Originalprojekt geflossen)

VPN Deployment auf den Hosts

Von nun an war die Verknüpfung der Hosts miteinander ein Kinderspiel. Docker und Docker-Compose waren auf den meisten Maschinen schon vorhanden. Für die Integration eines neuen Hosts in das Wartungsnetz waren nur noch 2 Schritte notwendig:

1) Docker-Compose File auf den Host kopieren

version: '3'
services:
peervpn:
image: thomasleister/peervpn
container_name: "peervpn"
network_mode: "host"
cap_add:
- NET_ADMIN
restart: "always"
environment:
NETWORKNAME: srvnet
INTERFACE: "srvnet0"
PSK: "meintollerpresharedkey"
LOCAL: "0.0.0.0"
PORT: 7000
INITPEERS: "1.2.3.4 7000"
IFCONFIG4: "10.8.1.1/24"
ENABLERELAY: "yes"
ENABLEIPV6: "no"

(… und anpassen!)

2) PeerVPN starten

docker-compose up -d

Zur Überprüfung der Funktion kann die Ausgabe von PeerVPN beobachtet werden:

docker-compose logs -f peervpn

Nach wenigen Sekunden können sich alle teilnehmenden Hosts über die 10.8.1.x-IP-Adressen erreichen, oder auf dem srvnet0 Interface eigene Dienste über dieses Netz verfügbar machen.

Automatische Updates mit Watchtower

Ein generelles Problem beim Einsatz von Docker sind fehlende, automatische Updates. So würde mein Alpine-Linux-Container mit PeerVPN nach dem ersten Pull des Images immer mit demselben Softwarestand laufen bzw. wieder gestartet werden. LibreSSL-Updates würden meinen Container nicht ohne weiteres Zutun erreichen. Ich müsste ständig selbst nachsehen, ob es Updates für Alpine Linux gibt, dann mein Image ggf. neu bauen und auf allen Hosts dieses neue Image downloaden, um dann meine PeerVPN-Container neu zu starten.

Mein eigenes PeerVPN-Image auf DockerHub kann ich automatisch neu bauen lassen, wenn das Basisimage (Alpine Linux Official) sich verändert. Doch wie kommt das aktuelle PeerVPN-Image auf meine Hosts? Auch hierfür gibt es eine Lösung: Watchtower

Das Tool wird selbst als Container auf den Hosts gestartet und überwacht alle aktiven Container. Ändert sich das Image, auf dem ein Container basiert, erkennt Watchtower das, lädt das neue Image herunter und startet die entsprechenden Container neu.

Neben meinen PeerVPN-Containern habe ich auf jedem der Hosts also auch einen Watchtower-Container gestartet. Der nützt mir nicht nur im Zusammenhang mit PeerVPN, sondern generell bei allen Docker-Containeranwendungen. Der zusätzliche Aufwand fiel für mich daher nicht so sehr ins Gewicht.

version: '3'
services:
watchtower:
image: v2tec/watchtower
container_name: "watchtower"
restart: "always"
volumes:
- "/var/run/docker.sock:/var/run/docker.sock"
command: "--interval 300 --cleanup"

Watchtower starten:

docker-compose up -d

Wer nur einzelne Container auf Updates überwachen lassen will, kann den “command” Parameter z.B. wie folgt erweitern:

command: "--interval 300 --cleanup meincontainer1 meincontainer2 meincontainer3"

(Übrigens: Watchtower aktualisiert nicht nur andere Container, sondern konsequenterweise auch sich selbst)

Fazit

Meine Hosts sind nun allesamt miteinander sicher vernetzt. Monitoring-Tools und andere verteilte Anwendungen können nun miteinander verknüpft werden, als wären sie in einem gemeinsamen, lokalen Netz. Das nimmt einem nicht nur Arbeit bei der Konfiguration ab, sondern sorgt auch für eine striktere Trennung zwischen Administrator-Diensten und öffentlichen Diensten.

Durch die Kapselung der VPN-Software in einem Docker-Container und die automatischen Updates via Watchtower muss ich mir keine Gedanken mehr um Updates und Kompatibilität mit dem Hostsystem machen. Neue Hosts sind zudem schnell in das bestehende Netz integriert.

Wer ein solches Wartungsnetz auch für seine Infrastruktur nutzen will, kann gerne auf mein Docker-Image und die oben genannten Docker-Compose-Files zurückgreifen.

Übrigens: Die 10.8.1.x-Adressen der Hosts habe ich im DNS verfügbar gemacht. So könnte z.B. 10.8.1.1 auf meinhost.srvnet.domain.tld gemappt sein. Das erleichtert den Umgang mit den IP-Adressen

Update am 11.09.2017: Ggf. starten Dienste nach einem Reboot nicht mehr, weil sie versuchen, Ports auf der srvnet0-Schnittstelle zu belegen, welche zu diesem Zeitpunkt aber noch nicht existiert. Der Docker-Container mit PeerVPN benötigt etwas Zeit, bis er hochgefahren ist. Eine Lösung für dieses Problem stelle ich in diesem Beitrag vor: Systemd: Dienst-Start von Netzwerk-Interface abhängig machen.

Powerwalker UPS unter Debian 9 Stretch

thomas.leister@mailbox.org (Thomas Leister) — Sun, 03 Sep 2017 17:29:00 +0200

Mit der Umstellung meines Homeservers auf Debian 9 Stretch war es auch an der Zeit, sich einmal um die daran angeschlossene Unterbrechungsfreie Stromversorgung (“UPS”: Uninterruptible Power Supply) zu kümmern. Mit dem Kauf der UPS hatte ich die Herstellersoftware zur Überwachung und zum Automatischen Herunterfahren des Servers auf selbigem installiert. Nach kurzer Zeit gefiel mir die aufgeblähte und schlecht gepflegte Java-Lösung allerdings nicht mehr und ich verzichtete auf eine UPS-Softwarekomponente auf dem Server. Das hatte zwar den Nachteil, dass der Server bei Stromausfall nicht automatisch heruntergefahren würde, aber eine Gewisse Überbrückungszeit war durch die UPS ja noch gegeben.

Nachdem letzte Woche der Strom für etwa eine Stunde ausgefallen war, und die UPS wegen eines zu alten Akkus nicht mehr funktionstüchtig war, kam das Thema “UPS” bei mir wieder auf, und ich wollte einmal sehen, was ich mit einem neuen Akku und einer Kopplung mit meinem Linux-Server anrichten kann. Als Alternative zu der Herstellersoftware “ViewPower” (die sich übrigens nicht mehr installieren ließ) stieß ich auf NUT - Network UPS Tools. Meine PowerWalker VI 600 LCD ist auf der Liste der kompatiblen Geräte zwar nur als “mäßig kompatibel” markiert, aber solange ich Messwerte auslesen konnte, und der Server bei schwach werdender Batterie automatisch heruntergefahren würde, war ich zufrieden. Also gab ich NUT eine Chance. Die Einrichtung von NUT will ich in diesem Beitrag kurz beleuchten.

UPS-Monitoring mit NUT

Alle notwendigen Softwarepakete werden durch

apt install nut

installiert. Dazu gehören die 3 Komponenten eines NUT Systems: Der passende Treiber für die UPS, upsd und upsmon. Upsd ist der Daemon, der mithilfe des Treibers die Verbindung zur UPS herstellt (Server). Upsmon greift als Client auf upsd zu, überwacht die Messwerte und leitet Aktionen wie z.B. Herunterfahren des Systems ein. Damit keine Verwirrung entsteht, sollte man diese Dreiteilung im Hinterkopf behalten.

(Hintergrund: upsd und upsmon sind getrennte Softwarekomponenten, damit sich mehrere UPS-Monitore/Server über des Netzwerk zu einem upsd / zu einer UPS verbinden können. Das ist sinnvoll, wenn mehrere Server an einer UPS hängen.)

Treiber einrichten und UPS verfügbar machen

Um ein einfaches Setup mit NUT zu realisieren, wird in der Konfigurationsdatei /etc/nut/nut.conf MODE auf standalone gesetzt:

MODE=standalone

Dann wird der passende Treiber für die UPS aktiviert. In meinem Fall muss der “blazer_usb” Treiber aktiviert werden. Welcher Treiber zu welchem UPS-Modell passt, kann man auf der Kompatibilitätsliste des NUT Projekts nachschlagen. In der Konfigurationsdatei /etc/nut/ups.conf wird unten folgendes Snippet angehängt:

[powerwalker]
driver = blazer_usb
port = auto
desc = "Meine Powerwalker UPS"

Damit wird die UPS bekannt gemacht und der passende Treiber aktiviert. Auf meinem Debian-System hatte NUT standardmäßig keinen Zugriff auf das USB-Device der UPS. So konnte NUT nicht funktionieren. Also habe ich mir via lsusb eine Liste der angeschlossenen USB-Geräte ausgeben lassen. Zur UPS gehörte der folgende Eintrag:

Bus 004 Device 002: ID 0665:5161 Cypress Semiconductor USB to Serial

Aus Vendor- und Product-ID (0665, 5161) konnte ich nun in /etc/udev/rules.d/90-nut-ups.rules eine neue Udev-Regel erstellen, welche NUT beim Anschließen des USB-Geräts die passenden Rechte für das Device gibt:

ACTION=="add", \
SUBSYSTEM=="usb", \
ATTR{idVendor}=="0665", ATTR{idProduct}=="5161", \
MODE="0660", GROUP="nut"

Vendor-ID und Product-ID müssen in der Konfiguration auf die Ausgabe von lsusb angepasst werden. Die Udev-Regelsätze habe ich anschließend via

udevadm control --reload-rules
udevadm trigger

aktiviert. Das “trigger” Kommando hat bei mir nicht auf Anhieb funktioniert, also habe ich die UPS kurzerhand nochmal getrennt und neu via USB verbunden.

Mit dem upsdrvctl start Kommando kann nun überprüft werden, ob die UPS korrekt erkannt wurde. Wenn alles okay ist, ist folgende Zeile in der Ausgabe zu lesen:

Supported UPS detected with mustek protocol

UPSd konfigurieren

Im nächsten Schritt wird der UPS-Daemon - der UPS-Server - eingerichtet. Dazu wird in /etc/nut/upsd.conf unten das folgende Snippet angefügt, welches nur lokale Zugriffe auf upsd erlaubt:

ACL all 0.0.0.0/0
ACL localhost 127.0.0.1/32
ACCEPT localhost
REJECT all

In /etc/nut/upsd.users wird außerdem ein neuer Benutzer angelegt, der Zugriff auf den Daemon haben soll. (folgendes unten anfügen:)

[local_mon]
password = mypass
allowfrom = localhost
upsmon master
instcmds = ALL

das Passwort “mypass” kann dabei natürlich frei gewählt werden.

UPSMon konfigurieren

Damit der UPS Monitor die neu eingerichtete UPS überwacht, wird in /etc/nut/upsmon.conf der folgende Abschnitt angefügt:

MONITOR powerwalker@localhost 1 local_mon mypass master
POWERDOWNFLAG /etc/killpower
SHUTDOWNCMD "/sbin/shutdown -h now"

Das Passwort entspricht dabei dem oben gewählten.

NUT starten

Die NUT-Dienste für Server und Monitor werden jetzt gestartet:

systemctl start nut-server
systemctl start nut-client

Es lohnt sich, via systemctl status nut-server bzw. systemctl status nut-client einen kurzen Blick auf den aktuellen Status der Dienste zu werfen, um zu sehen, ob die Konfiguration korrekt ist, und die Dienste ordnungsgemäß arbeiten.

UPS-Werte ausgeben

Aktuelle Werte zu Batteriespannung, Netzspannung und -Frequenz und eine menge weiterer Statusinformationen können jetzt mit

upsc powerwalker

ausgegeben oder via

watch -n 1 upsc powerwalker

beobachtet werden.

Auch Einstellungen wie z.B. die Aktivierung des Alarmsignals bei einer Netzstörung können verändert werden:

upscmd -u local_mon -p mypass powerwalker@localhost beeper.toggle

(auf das Passwort “mypass” achten!). Ein kurzer Batterietest kann via

upscmd -u local_mon -p mypass powerwalker@localhost test.battery.start.quick

duchgeführt werden. Eine Liste aller sog. “Instant commands” findet ihr hier: http://networkupstools.org/docs/developer-guide.chunked/apas02.html

Referenzen: https://blog.shadypixel.com/monitoring-a-ups-with-nut-on-debian-or-ubuntu-linux/

Mailserver mit Dovecot, Postfix, MySQL und Rspamd unter Debian 9 Stretch

thomas.leister@mailbox.org (Thomas Leister) — Fri, 04 Aug 2017 11:53:00 +0200

Ziel dieser für Debian 9 “Stretch” aktualisierten Anleitung ist ein fertig installierter und konfigurierter Mailserver auf einem eigens dafür bereitgestellten Host. Der Beitrag basiert im wesentlichen auf dem zuvor für Ubuntu 16.04 vorgestellten Setup. In dieser aktualisierten Version wird statt eines Amavis-Spamassassin-Razor Stacks und OpenDKIM allerdings Rspamd genutzt, um die Komplexität und Fehleranfälligkeit des Setups zu reduzieren und gleichzeitig von der hervorragenden Funktion des Rspam Daemons zu profitieren. Außerdem wurden in diese Anleitung einige kleine Verbesserungen eingebracht, die mir von Lesern in den letzten Monaten vorgeschlagen wurden.

Wie auch in den letzten Versionen ist mir wichtig, die Funktionsweise und das Zusammenspiel der Mailserver-Komponenten so zu erklären, dass das Mailsystem als solches in den Grundzügen verstanden werden kann. Ich setze dabei grundlegende Kenntnisse im Bereich Linux-Server voraus; trotzdem ist dieser Guide auch für Anfänger geeignet, die Interesse und Zeit mitbringen.

Eine neue Anleitung für Debian 10 “Buster” steht in den Startlöchern! Ich habe einige Detailverbesserungen in die Anleitung einfließen lassen. Datenbankgeschema und Dateisystemstruktur bleiben erhalten, sodass ein einfacher Umstieg auf das neue Setup möglich ist. Das neue Setup befindet sich noch in der Erprobungsphase. Wenn du es trotzdem ausprobieren möchtest, kannst du die neue Anleitung hier finden: https://thomas-leister.de/mailserver-debian-buster/

Wer lieber auf eine fertige Lösung setzt und sich die Handarbeit sparen will, sollte sich einmal Mailcow von André Peters ansehen.

Mailserver-Funktionen

Damit ihr einen Eindruck vom Funktionsumfang des fertigen Mailsetups bekommt, hier einige Merkmale:

Senden und Empfangen von E-Mails für beliebige Domains
Flexible Einrichtung von Domains, Mailaccounts, Aliasen, Weiterleitungen und Regeln für die Transportverschlüsselung über ein MySQL-Backend zur Laufzeit
Nutzer-spezifisch begrenztes Mailbox-Volumen
Einrichtung allgemeiner und Nutzer-spezifischer Sieve-Filterregeln zum filtern und/oder Umsortieren von eingehenden E-Mails
Hochperformante Spam-Früherkennung via Postscreen
Erweiterte Spamerkennung via Rspamd (+ Weboberfläche für Spam-Statistiken)
“Send only” Accounts z.B. für NextCloud / Forensoftware / …
DKIM-Signierung ausgehender E-Mails

Eine Weboberfläche / ein Management-Tool zur Verwaltung dieses Setups biete ich selbst nach wie vor nicht an. In der Zwischenzeit haben aber andere User Lösungen veröffentlicht, z.B.

Florian Kapfenberger: Mailman (nicht zu verwechseln mit Mailman, dem Mailinglist-Manager!)
Andreas Bresch: VmailManage
Henrik Halbritter: MailAdmin
awidegreen: vmail-rs (CLI-Tool!)
pprugger: vmail-admin
Kekskurse: Go-Mail-Admin

Das Datenbank-Layout und die Struktur des /var/vmail-Verzeichnisses haben sich im Vergleich zur vorherigen Anleitung nicht geändert. Ein Update älterer Setups ist also einfach realisierbar.

Verwendete Software

Debian 9 “Stretch”
Postfix
Dovecot
Rspamd
Redis
MariaDB
Nginx (optional)

Dieses Setup ist standardmäßig nicht vollständig kompatibel mit Ubuntu Server! Die Distribution liefert aktuell (Stand Januar 2018) eine ältere Version von Dovecot mit, sodass beispielsweise imap_sieve nicht verfügbar ist. Das Problem kann behoben werden, indem für Ubuntu Server das PPA https://launchpad.net/%7Epdoes/+archive/ubuntu/dovecot für eine aktuellere Dovecot-Version hinzugefügt wird.

Gegebenheiten

In dieser Anleitung kommen folgende Domains vor:

mysystems.tld: Übergeordnete, primäre Domain
mail.mysystems.tld: Subdomain, unter der der Mailserver verfügbar sein soll (FQDN des Mailsystems)
imap.mysystems.tld: Alias auf mail.mysystems.tld, wird von vielen Mailclient automatisch gesucht und gefunden
smtp.mysystems.tld: Dasselbe für den SMTP-Dienst
domain2.tld: Eine zweite Domain neben mysystems.tld, für die E-Mails gesendet und empfangen werden sollen
domain3.tld: Eine dritte Domain, für die E-Mails gesendet und empfangen werden sollen

Diese Domains müssen in der gesamten Anleitung selbstverständlich durch eigene ersetzt werden!
Auf domain2.tld und domain3.tld kann verzichtet werden, wenn der Mailserver nur für eine Domain (nur für “@mysystems.tld”-Adressen) genutzt werden soll.

Grundvoraussetzungen für den Mailserver

Ein virtueller oder dedizierter Server mit bereits installiertem Debian 9 Stretch
(“Standard-Systemwerkzeuge” und “SSH” bei der Installation angewählt)
Mindestens eine eigene Domain + volle Kontrolle über die DNS-Zone

Ein kleiner, virtueller Server auf KVM-Basis ist in den meisten Fällen völlig ausreichend. Ich empfehle für kleine, private Setups zwei CPU-Kerne und 1-2 GB RAM. Virtuelle Server kann man z.B. bei Hetzner bekommen.

Komponenten eines vollständigen Mailsystems

Welche Softwarekomponenten verwendet werden, wisst ihr bereits. Doch welche Software übernimmt welche Aufgaben?

Dovecot

Dovecot ist ein weit verbreiteter MDA (Mail Delivery Agent) und IMAP-Server. Er sortiert ankommende E-Mails in die Postfächer des jeweiligen Empfängers ein und stellt eine Schnittstelle zum Abrufen der Mailbox bereit (IMAP). Außerdem wird Dovecot in diesem Setup von Postfix als sog. SASL-Authentifizierungsserver genutzt: Postfix fragt Dovecot, ob ein bestimmter Benutzer berechtigt ist, sich am System anzumelden.

Aufgaben: Verwaltung der Mailbox, Bereitstellung einer Schnittstelle zum Abrufen erhaltener E-Mails, SASL-Authentifizierungsserver (überprüft Benutzeranmeldung)

Postfix

Postfix wird oft zusammen mit Dovecot eingesetzt. Der populäre MTA (Mail Transfer Agent) kümmert sich um alles, was mit dem Transport der E-Mail zu tun hat: Vom E-Mail Client zum eigenen Mailserver, und von dort aus zum jeweiligen Zielserver. Außerdem nimmt Postfix E-Mails von fremden Servern an und leitet sie an den MDA Dovecot weiter. Antispam-Software wird i.d.R. direkt in Postfix integriert, um eintreffende Spammails erst gar nicht in die Mailbox des Nutzers gelangen zu lassen.

Aufgaben: E-Mail-Transport und -Filterung

Anmerkung: Postfix ist “der eigentliche Mailserver”. E-Mails können ohne weiteres einzig und allein mit Postfix gesendet und empfangen werden. Alle weiteren Komponenten wie Dovecot und Rspamd machen uns das Leben allerdings einfacher ;-)

MariaDB (MySQL-Datenbank)

Dovecot und Postfix werden so konfiguriert, dass sie eine MySQL-Datenbank als Backend (Datenbasis) nutzen. In der Datenbank werden zu nutzende Domains, Benutzer, Aliase und weitere Daten gespeichert. Durch einfaches Hinzufügen oder Entfernen von Datensätzen in oder aus Datenbanktabellen können neue Benutzer oder Aliase angelegt oder gelöscht werden. Der Vorteil eines Datenbank-Backends ist, dass sich der Mailserver damit sehr einfach verwalten lässt: So ließe sich zur Benutzerverwaltung beispielsweise eine Weboberfläche in PHP entwickeln, die die MySQL-Datenbank verändert. Die Serverkonfiguration muss dann nicht manuell geändert werden.

Aufgaben: Bereitstellung Betriebsdaten für Postfix und Dovecot

Rspamd

Rspamd ist ein Filtersystem, das in Postfix integriert wird und eingehende E-Mails überprüft. Spammails werden von Rspamd erkannt und nicht an den Benutzer zugestellt bzw. aussortiert. Außerdem fügt Rspamd bei ausgehenden E-Mails eine DKIM-Signatur hinzu, sodass fremde Mailserver eigene Mails nicht als verdächtig einstufen.

Aufgaben: Filtern von Spam, DKIM-Signierung

Nginx (optional)

Nginx ist ein beliebter und schlanker Webserver / Webproxy. Hier wird er als HTTP-Proxy vor Rspamd verwendet, um die Weboberfläche des Spamfilters abgesichert nach außen hin zugänglich zu machen.

Aufgaben: Proxying für Rspamd-Weboberfläche

Redis

Redis ist ein hochperformanter In-memory Key-Value-Store, also eine sehr einfache, schnelle Datenbank, welche Schlüssel-Wert-Paare effizient im Speicher ablegen kann. Rspamd nutzt Redis, um einige Daten zwischenzuspeichern (wie z.B. zuletzt Überprüfte Mailserver).

Aufgaben: Caching, Memory

Vorbereitungen

Tipp: Reinen Tisch machen

Wenn ihr den Server vorher schon für etwas anderes (oder sogar ein anderes Mail-Setup) verwendet habt, stellt sicher, dass Reste aus alten Installationen das neue Setup nicht behindern. Speziell vorherige Mailserver-Versuche sollten rückstandslos entfernt werden (inkl. der zugehörigen Konfigurationsdateien). Am besten ist natürlich – falls möglich – eine komplette Neuinstallation des Servers. Ich empfehle, den Mailserver als eigenständiges System zu betreiben und auf demselben Host keine anderen Dienste zu installieren, um die Integrität des Mailsystems sicherzustellen.

Im Folgenden gehe ich von einem frisch installierten Debian 9 Stretch aus (zusätzlich nur “Standard-Systemwerkzeuge” und SSH installiert).

Bei der Installation von Debian wird ein normaler Benutzeraccount, z.B. “thomas” eingerichtet, zu dem ihr euch via Passwort verbinden könnt. Der Root-Account ist standardmäßig nicht direkt zugänglich, sondern nur über den Umweg via “su”. Für diese Anleitung werden permanent Root-Rechte benötigt. Öffnet nach dem Login am Server also am besten eine Root-Kommandozeile via

su

Gebt dann das Passwort für euren root-User ein.

System aktualisieren

Bevor ihr neue Software-Pakete installiert, solltet ihr mittels

apt update && apt upgrade

sicherstellen, dass euer System aktuell ist. Bei der Gelegenheit bietet sich auch gleich ein Reboot an, um einen möglicherweise aktualisierten Linux-Kernel zu laden.

Hostname und Server-FQDN setzen

Euer Server bekommt zwei Namen, über die er identifiziert werden kann:

Lokalen Hostnamen: Für die Identifizierung des Servers innerhalb der eigenen Infrastruktur, z.B. “mail”
FQDN (Fully Qualified Domain Name): Für die weltweite Identifizierung im Internet, z.B. “mail.mysystems.tld”

Der FQDN muss nicht zwingend etwas mit den Domains zu tun haben, für die später E-Mails gesendet und empfangen werden sollen. Wichtig ist nur, dass euer künftiger Mailserver einen solchen Namen hat, der auch über das DNS zur Server-IP-Adresse aufgelöst werden kann (dazu gleich mehr im Abschnitt “Einrichtung des DNS”). Den lokalen Hostnamen setzt ihr wie folgt:

hostnamectl set-hostname --static mail

In der Hosts-Datei /etc/hosts sollten FQDN und lokaler Hostname hinterlegt sein. Die Datei kann beispielsweise so aussehen:

127.0.0.1 localhost
127.0.1.1 mail.mysystems.tld mail
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Die Ausgaben der Kommandos hostname und hostname --fqdn sollten nach den Änderungen wie folgt aussehen:

root@mail:~# hostname
mail
root@mail:~# hostname --fqdn
mail.mysystems.tld

Der FQDN (in diesem Beispiel “mail.mysystems.tld”) wird außerdem nach /etc/mailname geschrieben:

echo $(hostname -f) > /etc/mailname

(Der Hostname im Shell-Prompt z.B. root@meinhost: passt sich erst nach einem erneuten Login an.)

Tipp: Unbound DNS Resolver installieren

Das Mailsystem benötigt einen funktionierenden DNS-Server (Resolver), sodass die Herkunft von E-Mails überprüft werden kann. Auch der Rspamd-Spamfilter verlässt sich bei der Bewertung von Spammails auf DNS-Dienste. Eine schnelle Namesauflösung bringt also Performancevorteile für das ganze Mailsystem. Für den Zugriff auf Spamhaus-Blocklists (wie sie später verwendet werden) kann es sogar notwendig sein, seinen eigenen DNS-Resolver zu nutzen, weil z.B. Zugriffe über das Google DNS blockiert werden. Deshalb (und um die Sicherheit im Bezug auf Abhängigkeiten zu fremden Systemen zu verbessern) empfehle ich die Nutzung eines eigenen, lokalen DNS-Resolvers.

Unbound installieren:

apt install unbound

DNSSEC Root Key aktualisieren und Unbound neu laden:

su -c "unbound-anchor -a /var/lib/unbound/root.key" - unbound
systemctl reload unbound

Für die nächsten Kommandos muss das Paket “dnsutils” installiert sein. Wenn bei der Installation von Debian die “Standard-Systemwerkzeuge” ausgewählt wurden, sind die Tools schon installiert.

Ein dig @127.0.0.1 denic.de +short +dnssec sollte eine ähnliche Ausgabe wie folgt erzeugen:

dig @127.0.0.1 denic.de +short +dnssec
81.91.170.12
A 8 2 3600 20170814090000 20170731090000 26155 denic.de. Jo90qnkLkZ6gI4qNHj19BMguFuGof9hCPhdeSh/fSePSQ/WXlWMmfjW1 sNDJ/bcITRMyz8DQdDzmWPDIeSJ/qPyfoZ+BjUZxtaXcs0BAl4KX8q7h R05TGmAbgPhrYBoUKJkU/q8T+jWKHAJRUeWbCd8QOJsJbneGcUKxRAPe i6Rq51/OL/id6zUCtalhclah2TfLLaqku9PmKwjbGdZm11BXSr8b56LB WX/rdLIrKWNpE+jHGAUMmDsZL84Kx3Oo

Wenn der dig-Befehl funktioniert hat, kann der lokale Resolver als primärer Resolver gesetzt werden:

apt install resolvconf
echo "nameserver 127.0.0.1" >> /etc/resolvconf/resolv.conf.d/head

ein nslookup denic.de | grep Server sollte nun

Server: 127.0.0.1

zurückliefern. Damit ist der lokale DNS-Resolver als Haupt-Resolver einsatzbereit.

Einrichtung des DNS

Zu Beginn dieser Anleitung wurde für den Mailserver der FQDN “mail.mysystems.tld” festgelegt. Für diesen Domain-Namen werden nun A-Records im DNS-Zonefile der Domain “mysystems.tld” erstellt. Loggt euch bei eurem Domain-Provider ein und legt die folgenden Einträge an – der erste für die IPv4-IP-Adresse des Mailservers, die zweite für die IPv6-Adresse. (Beispiel!): Achtet im Folgenden vor allem auf den abschließenden Punkt in den Domainnamen!

mail.mysystems.tld. 86400 IN A 5.1.76.155
mail.mysystems.tld. 86400 IN AAAA 2a00:f820:417::be19:7b23

“mail.mysystems.tld” ist damit im DNS bekannt. Wenn keine IPv6-Adresse genutzt wird, kann der zweite Record entfallen. Bleiben noch “imap.mysystems.tld” und “smtp.mysystems.tld”, die als Alias-Domains für “mail.mysystems.tld” angelegt werden. Sie sind nicht unbedingt notwendig, werden von vielen Mailclient aber gesucht und sind so üblich:

imap.mysystems.tld. 86400 IN CNAME mail.mysystems.tld.
smtp.mysystems.tld. 86400 IN CNAME mail.mysystems.tld.

Mailclients können sich damit schon über imap.mysystems.tld und smtp.mysystems.tld zum Mailserver verbinden. Andere Mailserver suchen bei der E-Mail-Übermittlung allerdings nicht nach A- oder CNAME-Records, sondern nach MX-Records. Ein MX-Record zeigt, welcher Mailserver für die E-Mails zu einer Domain zuständig ist. In meinem Beispiel soll sich unser Mailserver neben den E-Mails für mysystems.tld auch um die Mails für domain2.tld und domain3.tld kümmern.

Im Zonefile der Domain “mysystems.tld” wird dazu dieser Record angelegt:

mysystems.tld. 86400 IN MX 0 mail.mysystems.tld.

In die Zonefiles der anderen Domains werden entsprechend die Records

domain2.tld. 86400 IN MX 0 mail.mysystems.tld.

und

domain3.tld. 86400 IN MX 0 mail.mysystems.tld.

angelegt.

Reverse DNS

Des weiteren muss ein sog. Reverse-DNS-Record / PTR für den FQDN des Mailservers angelegt werden. Dieser entspricht der Umkehrung eines normalen DNS-Records und ordnet einer IP-Adresse einen Hostnamen zu. Diesen Record kann nur der Inhaber des Netzes anlegen, aus dem eure IP-Adresse stammt. Möglicherweise könnt ihr so einen Reverse-DNS-Record in der Verwaltungsoberfläche eures Serveranbieters setzen, oder ihr bittet den Support, das zu tun. Der Domain-Name, der mit der IP-Adresse verknüpft werden muss, ist der FQDN eures Mailservers. In meinem Beispiel mail.mysystems.tld. Denkt daran, für alle vom Mailserver genutzten, öffentlichen IP-Adressen einen solchen Record zu erstellen. In dieser Anleitung wird eine IPv4- und eine IPv6-Adresse verwendet.

SPF-Records

Im Kampf gegen Spam und Phishing wurde das sog. Sender Policy Framework entwickelt (Siehe auch Beitrag: “Voraussetzungen für den Versand zu großen E-Mail Providern”). Obwohl es sich nur als eingeschränkt brauchbar erwiesen hat, erwarten die meisten Mailprovider gültige SPF-Records für andere Mailserver und prüfen diese. SPF-Einträge werden im Zonefile aller Domains erstellt, für die ein Mailserver E-Mails verschickt, und geben an, welche Server für eine Domain sendeberechtigt sind. Für unsere Domain mysystems.tld wird der folgende Record im Zonefile von mysystems.tld angelegt:

mysystems.tld. 3600 IN TXT v=spf1 a:mail.mysystems.tld ?all

Hiermit erhält nur der im A-Record “mail.msystems.tld” genannte Server für mysystems.tld eine Sendeberechtigung. Die Neutral-Einstellung “?all” sorgt dafür, dass E-Mails von anderen Servern trotzdem angenommen werden sollen. Damit gehen wir Problemen beim Mail-Forwarding aus dem Weg. Wir erstellen den SPF-Record also eigentlich nur, damit andere Mailserver unseren Server wegen des existierenden Records positiv bewerten – nicht, weil er seinen Nutzen entfalten soll.

In den Zonefiles der beiden Domains “domain2.tld” und “domain3.tld” wird (angepasst auf die Domain) jeweils dieser Record angelegt:

domain2.tld. 3600 IN TXT v=spf1 include:mysystems.tld ?all

Über das “include” wird der erste Record der Domain mysystems.tld eingebunden.

DMARC Records

DMARC-Einträge bestimmen, was ein fremder Mailserver tun soll, wenn eine von ihm empfangene Mail nach SPF- und DKIM-Checks offenbar nicht vom korrekten Mailserver stammt (wenn der Absender also gefälscht wurde). Es ist vernünftig, andere Mailserver anzuweisen, solche E-Mails nicht zu akzeptieren:

_dmarc.mysystems.tld. 3600 IN TXT v=DMARC1; p=reject;

Der Record wird entsprechend auch für die anderen Domains gesetzt:

_dmarc.domain2.tld. 3600 IN TXT v=DMARC1; p=reject;

Einen DMARC-Record mit einer abweichenden Policy könnt ihr euch unter https://elasticemail.com/dmarc/ selbst generieren lassen.

Einrichtung der TLS-Zertifikate (Let’s Encrypt)

Gültige TLS-Zertifikate von anerkannten Zertifizierungsstellen (CAs) sind heute für jeden Mailserver ein “muss”. Immer mehr Mailsysteme verweigern zurecht den Empfang über ungesicherte Verbindungen. Was früher (vor allem für den privaten Einsatz) noch ein bedeutender Kostenfaktor war, bekommt man heute Dank Let’s Encrypt kostenlos und sehr unkompliziert. Im folgenden beziehe ich mich daher auf die Generierung von Let’s Encrypt-Zertifikaten. Selbstverständlich können stattdessen auch Zertifikate anderer CAs genutzt werden.

Abholen neuer Zertifikate

Der kürzeste Weg zu neuen Zertifikaten führt über den offiziellen Let’s Encrypt Client “Certbot”:

apt install certbot
certbot certonly --standalone --rsa-key-size 4096 -d mail.mysystems.tld -d imap.mysystems.tld -d smtp.mysystems.tld

Nach Zustimmung der Nutzungsbedingungen sind innerhalb von wenigen Sekunden neue, gültige TLS-Zertifikate auf dem System installiert. Mit dem neuen Zertifikat unter /etc/letsencrypt/live/mail.mysystems.tld sind die drei Domains

mail.mysystems.tld
imap.mysystems.tld
smtp.mysystems.tld

abgesichert. Im oben genannten Verzeichnis befinden sich drei Dateien:

cert.pem: Das eigentliche Zertifikat
chain.pem: CA Zertifikat
fullchain.pem: Das Zertifikat + CA Zertifikat
privkey.pem: Der geheime Zertifikats-Schlüssel

später werden nur die letzten beiden Zertifikatsdateien verwendet.

Automatische Erneuerung

Let’s Encrypt-Zertifikate laufen nach 90 Tagen aus und sind dann ungültig. Deshalb sollten die Zertifikate regelmäßig erneuert werden - zum Beispiel über den folgenden CronJob:

@weekly certbot renew --pre-hook "systemctl stop nginx" --post-hook "systemctl start nginx" --renew-hook "systemctl reload nginx; systemctl reload dovecot; systemctl reload postfix" --quiet

Dieser Eintrag wird nach der Eingabe von

crontab -e

(und der anschließenden Wahl des bevorzugten Editors - Empfehlung: nano) in die Cron-Datei unten eingetragen und gespeichert.

MySQL Datenbank einrichten

Informationen über zu verwaltende Domains, Benutzer, Weiterleitungen und sonstige Einstellungen soll der Mailserver aus einer MySQL-Datenbank ziehen. Das hat den Vorteil, dass der Server im laufenden Betrieb flexibel angepasst werden kann, ohne die Konfigurationsdateien ändern zu müssen. Die Datenbank ermöglicht uns außerdem ein virtualisiertes Mailserver-Setup: Die Benutzer auf den Mailservern müssen nicht mehr als reale Linux-Benutzer im System registriert sein, sondern nur noch in der Datenbank eingetragen werden.

Als DBMS wird die neue Debian-Standard-MySQL-Datenbank “MariaDB” installiert:

apt install mariadb-server

Nach der Installation sollte MariaDB bereits gestartet sein. Den Status könnt ihr mittels systemctl status mysql (nicht “mariadb!”) überprüfen. Falls das nicht der Fall ist, startet den Datenbankserver: systemctl start mysql.

Standardmäßig kann sich nur der root-Systemuser am Datenbankserver anmelden. Authentifiziert wird er dabei automatisch via PAM, sodass keine zusätzliche Passworteingabe notwendig ist. Die einfache Eingabe von

mysql

bringt euch in eine MySQL Root Shell. Über diese werden nun ein paar SQL-Befehle ausgeführt.

Ein SQL-Kommando endet immer mit einem Semikolon ;. Mehrzeilige Befehle könnt ihr ohne weiteres einfach mit ENTER umbrechen, so wie sie im Folgenden dargestellt werden. Achtet auf den Unterschied zwischen “Tick” (') und “Backtick” ( \ `) – der Backtick wird mit Shift + 2x Accent-Taste erzeugt. Kopiert die SQL-Statements am besten direkt in eure Zwischenanlage, statt sie mühsam abzutippen.

Im ersten Schritt wird eine neue Datenbank “vmail” angelegt.

create database vmail
CHARACTER SET 'utf8';

Ein neuer DB-User “vmail” mit dem Passwort “vmaildbpass” bekommt Zugriff auf diese neue Datenbank (Wählt ein eigenes Passwort statt “vmaildbpass”!):

grant select on vmail.* to 'vmail'@'localhost' identified by 'vmaildbpass';

Alle weiteren Kommandos zu Erstellung der Datenbank-Tabellen sollen sich auf die eben erzeugte Datenbank beziehen:

use vmail;

Das Mail-Setup soll 4 verschiedene Tabellen nutzen. Kopiert die SQL-Statements einzeln und nacheinander in die MySQL-Kommandozeile und bestätigt jedes mal mit [Enter]. Anpassungen sind nicht notwendig.

Domain-Tabelle

Die Domain-Tabelle enthält alle Domains, die mit dem Mailserver genutzt werden sollen.

CREATE TABLE `domains` (
`id` int unsigned NOT NULL AUTO_INCREMENT,
`domain` varchar(255) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY (`domain`)
);

Account-Tabelle

CREATE TABLE `accounts` (
`id` int unsigned NOT NULL AUTO_INCREMENT,
`username` varchar(64) NOT NULL,
`domain` varchar(255) NOT NULL,
`password` varchar(255) NOT NULL,
`quota` int unsigned DEFAULT '0',
`enabled` boolean DEFAULT '0',
`sendonly` boolean DEFAULT '0',
PRIMARY KEY (id),
UNIQUE KEY (`username`, `domain`),
FOREIGN KEY (`domain`) REFERENCES `domains` (`domain`)
);

Die Account-Tabelle enthält alle Mailserver-Accounts. Das Feld “quota” enthält die Volumenbegrenzung für die Mailbox in MB (Megabyte). Im Feld “enabled” wird über einen bool’schen Wert festgelegt, ob ein Account aktiv ist, oder nicht. So können einzelne User temporär deaktiviert werden, ohne gelöscht werden zu müssen. “sendonly” wird auf “true” gesetzt, wenn der Account nur zum Senden von E-Mails genutzt werden soll – nicht aber zum Empfang. Das kann beispielsweise für Foren- oder Blogsoftware sinnvoll sein, die mit ihrem Account nur E-Mails verschicken soll.

Alias-Tabelle

CREATE TABLE `aliases` (
`id` int unsigned NOT NULL AUTO_INCREMENT,
`source_username` varchar(64) NOT NULL,
`source_domain` varchar(255) NOT NULL,
`destination_username` varchar(64) NOT NULL,
`destination_domain` varchar(255) NOT NULL,
`enabled` boolean DEFAULT '0',
PRIMARY KEY (`id`),
UNIQUE KEY (`source_username`, `source_domain`, `destination_username`, `destination_domain`),
FOREIGN KEY (`source_domain`) REFERENCES `domains` (`domain`)
);

Die Alias-Tabelle enthält alle Weiterleitungen / Aliase und ist eigentlich selbsterklärend. Zur temporären Deaktivierung von Weiterleitungsadressen gibt es wieder ein “enabled”-Feld.

TLS Policy-Tabelle

CREATE TABLE `tlspolicies` (
`id` int unsigned NOT NULL AUTO_INCREMENT,
`domain` varchar(255) NOT NULL,
`policy` enum('none', 'may', 'encrypt', 'dane', 'dane-only', 'fingerprint', 'verify', 'secure') NOT NULL,
`params` varchar(255),
PRIMARY KEY (`id`),
UNIQUE KEY (`domain`)
);

Mithilfe der TLS Policy Tabelle kann festgelegt werden, für welche Empfängerdomains bestimmte Sicherheitsbeschränkungen beim Mailtransport gelten sollen. Für einzelne Domains, z.B. “gmx.de” kann beispielsweise angegeben werden, dass diese E-Mails nur noch verschlüsselt übertragen werden dürfen. Mehr dazu später.

Die Datenbank wird mit Datensätzen befüllt, sobald die Server fertig konfiguriert sind. Bis dahin könnt ihr die MySQL-Kommandozeile mit quit; verlassen.

vmail-Benutzer und -Verzeichnis einrichten

Alle Mailboxen werden direkt im Dateisystem des Debian Servers abgelegt. Für die Zugriffe auf die Mailbox-Verzeichnisse wird ein eigener Benutzer “vmail” (“Virtual Mail”) erstellt, unter dem die Zugriffe von Dovecot und anderen Komponenten des Mailservers geschehen sollen. Einerseits wird so verhindert, dass Mailserver-Komponenten auf sensible Systemverzeichnisse Zugriff bekommen, andererseits können wir so die Mailboxen vor dem Zugriff von außen schützen. Nur vmail (und root) dürfen auf die Mailboxen zugreifen.

Das Verzeichnis /var/vmail/ soll alle Mailserver-relevanten Dateien (also Mailboxen und Filterscripts) enthalten und wird für den vmail-User als Home Directory festgelegt.

vmail-Verzeichnis erstellen:

mkdir /var/vmail

vmail-Systembenutzer erstellen:

adduser --disabled-login --disabled-password --home /var/vmail vmail

vmail Unterverzeichnisse erstellen:

mkdir /var/vmail/mailboxes
mkdir -p /var/vmail/sieve/global

Verzeichnis /var/vmail an vmail-User übereignen und Verzeichnisrechte passend setzen:

chown -R vmail /var/vmail
chgrp -R vmail /var/vmail
chmod -R 770 /var/vmail

Dovecot installieren und konfigurieren

Nachdem die Datenbank und der vmail-User angelegt wurden, widmen wir uns nun dem Dovecot-Server. Wie bereits erwähnt, verwaltet dieser Server die Mailboxen und bekommt daher (in der Gestalt des vmail-Users) exklusiv Zugriff auf /var/vmail/. Zuerst müssen jedoch alle Serverkomponenten installiert werden:

apt install dovecot-core dovecot-imapd dovecot-lmtpd dovecot-mysql dovecot-sieve dovecot-managesieved

dovecot-core: Dovecot-Kern
dovecot-imapd: Fügt IMAP-Funktionalität hinzu
dovecot-lmtp: Fügt LMTP (Local Mail Transfer Protocol)-Funktionalität hinzu; LMTP wird als MTP-Protokoll zwischen Postfix und Dovecot genutzt
dovecot-mysql: Lässt Dovecot mit der MySQL-Datenbank zusammenarbeiten
dovecot-sieve: Fügt Filterfunktionalität hinzu
dovecot-managesieved: Stellt eine Schnittstelle zur Einrichtung der Filter via Mailclient bereit

Nach der Installation wird Dovecot automatisch gestartet. Beendet Dovecot, solange wir keine fertige Konfiguration haben:

systemctl stop dovecot

Nun geht es an die Konfiguration. Die Dovecot-Konfigurationsdateien liegen im Verzeichnis /etc/dovecot/. Dort könnt ihr schon einige Konfigurationen sehen, die bei der Installation angelegt wurden. Wir werden die Konfiguration von Grund auf neu aufsetzen - deshalb wird zuerst einmal die gesamte Dovecot-Konfiguration gelöscht:

rm -r /etc/dovecot/*
cd /etc/dovecot

Für Dovecot reichen die folgenden zwei Konfigurationsdateien (dovecot.conf und dovecot-sql.conf) aus. Erstellt die beiden Dateien im Verzeichnis /etc/dovecot/.

Hauptkonfigurationsdatei dovecot.conf

###
### Aktivierte Protokolle
#############################
protocols = imap lmtp sieve
###
### TLS Config
#######################
ssl = required
ssl_cert = </etc/letsencrypt/live/mail.mysystems.tld/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.mysystems.tld/privkey.pem
ssl_cipher_list = EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA
ssl_prefer_server_ciphers = yes
###
### Dovecot services
################################
service imap-login {
inet_listener imap {
port = 143
}
}
service managesieve-login {
inet_listener sieve {
port = 4190
}
}
service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
mode = 0660
group = postfix
user = postfix
}
user = vmail
}
service auth {
### Auth socket für Postfix
unix_listener /var/spool/postfix/private/auth {
mode = 0660
user = postfix
group = postfix
}
### Auth socket für LMTP-Dienst
unix_listener auth-userdb {
mode = 0660
user = vmail
group = vmail
}
}
###
### Protocol settings
#############################
protocol imap {
mail_plugins = $mail_plugins quota imap_quota imap_sieve
mail_max_userip_connections = 20
imap_idle_notify_interval = 29 mins
}
protocol lmtp {
postmaster_address = postmaster@mysystems.tld
mail_plugins = $mail_plugins sieve
}
###
### Client authentication
#############################
disable_plaintext_auth = yes
auth_mechanisms = plain login
passdb {
driver = sql
args = /etc/dovecot/dovecot-sql.conf
}
userdb {
driver = sql
args = /etc/dovecot/dovecot-sql.conf
}
###
### Mail location
#######################
mail_uid = vmail
mail_gid = vmail
mail_privileged_group = vmail
mail_home = /var/vmail/mailboxes/%d/%n
mail_location = maildir:~/mail:LAYOUT=fs
###
### Mailbox configuration
########################################
namespace inbox {
inbox = yes
mailbox Spam {
auto = subscribe
special_use = \Junk
}
mailbox Trash {
auto = subscribe
special_use = \Trash
}
mailbox Drafts {
auto = subscribe
special_use = \Drafts
}
mailbox Sent {
auto = subscribe
special_use = \Sent
}
}
###
### Mail plugins
############################
plugin {
sieve_plugins = sieve_imapsieve sieve_extprograms
sieve_before = /var/vmail/sieve/global/spam-global.sieve
sieve = file:/var/vmail/sieve/%d/%n/scripts;active=/var/vmail/sieve/%d/%n/active-script.sieve
###
### Spam learning
###
# From elsewhere to Spam folder
imapsieve_mailbox1_name = Spam
imapsieve_mailbox1_causes = COPY
imapsieve_mailbox1_before = file:/var/vmail/sieve/global/learn-spam.sieve
# From Spam folder to elsewhere
imapsieve_mailbox2_name = *
imapsieve_mailbox2_from = Spam
imapsieve_mailbox2_causes = COPY
imapsieve_mailbox2_before = file:/var/vmail/sieve/global/learn-ham.sieve
sieve_pipe_bin_dir = /usr/bin
sieve_global_extensions = +vnd.dovecot.pipe
quota = maildir:User quota
quota_exceeded_message = Benutzer %u hat das Speichervolumen überschritten. / User %u has exhausted allowed storage space.
}

Anzupassende Stellen:

ssl_cert: Pfad zur Zertifikatsdatei
ssl_key: Pfad zur Zertifikatsdatei
postmaster_address: Domain anpassen

Erklärung

dovecot.conf ist die Hauptkonfigurationsdatei des Dovecot-Servers:

Dovecot Services: Im darauf folgenden Abschnitt werden die Dovecot Services konfiguriert. Dazu gehört z.B. der Dienst “imap-login”, der auf eingehende Verbindungen von E-Mail Clients auf Port 143 horcht. Auch “managesieve-login” kommuniziert mit dem Mailclient, wenn dieser eine Funktion zur Bearbeitung Server-seitiger Filterscripte mitbringt. Die anderen Dienste werden intern genutzt: Der lmtp-Dienst stellt eine Schnittstelle bereit, über die Postfix empfangene Mails an die Mailbox übergeben kann. Der “auth” Dienst wird vom LMTP-Dienst genutzt, um die Existenz von Benutzern zu überprüfen, aber auch von Postfix, um den Login am Postfix-Server zu überprüfen. Mit “mode”, “user” und “group” wird bestimmt, welcher Systemuser Zugriff auf den Dienst haben soll (Analog zu den Dateirechten – der Socket für den Dienst ist nichts anderes als eine Datei).

Protocol settings: Für die verwendeten Protokolle können zusätzliche Einstellungen gesetzt werden – u.A. auch, welche Erweiterungen im Zusammenhang mit dem Protokoll genutzt werden sollen. “quota” und “imap_quota” sind notwendig, um das maximale Volumen einer Mailbox festsetzen zu können. Beim lmtp-Protokoll kann auf diese Erweiterungen verzichtet werden: Hier wird nur die Sieve-Erweiterung zum Filtern von E-Mails benötigt.

Client Authentication: Die Zeilen

disable_plaintext_auth = yes
auth_mechanisms = plain login

scheinen sich zu widersprechen, schließlich wird die Klartext-Authentifizierung abgeschaltet. Doch tatsächlich wird sie das nur für unverschlüsselte Verbindungen. TLS-Verschlüsselte Verbindungen bleiben davon unberührt, sodass in der nächsten Zeile die “plain” Authentifizierung mit Klartext-Passwörtern wieder angeboten werden kann. Das wird aus zwei Gründen getan:

“Klartext” tut uns hier nicht weh – schließlich ist die Verbindung sowieso (zwingend) verschlüsselt.
Alle Mailclients unterstützen die Klartextauthentifizierung. Andere Loginmechanismen werden weniger gut unterstützt und sind aufwendiger.

Wir konzentrieren uns deshalb auf die klassische Klartextauthentifizierung. Wie bereits erwähnt: Da unsere Verbindung ohnehin verschlüsselt ist, ist das in diesem Fall nicht sicherheitsrelevant.

Für “passdb” und “userdb” wird jeweils der Pfad zur SQL-Datei eingestellt. Dort befindt sich jeweils eine passende SQL-Query. Die “passdb” wird befragt, wenn es um die Authentifizierung von Usern geht, die “userdb”, wenn die Existenz eines bestimmten E-Mail Kontos überprüft werden soll, oder benutzerdefinierte Einstellungen geladen werden müssen, wie z.B. das Mailbox-Kontingent (“Quota”).

Maillocation: In diesem Abschnitt wird definiert, unter welchem Systemuser Dovecot auf Dateisystem-Ebene mit E-Mails hantieren soll. Außerdem wird ein Pfad-Schema festgelegt, das bestimmt, nach welcher Struktur die Mailbox-Verzeichnisse angelegt werden sollen. %d steht für die Domain des Accounts und %n für den Benutzernamen vor dem @. Der Pfad zu einer Benutzermailbox lautet z.B.: /var/vmail/mailboxes/mysystems.tld/admin/mail/

Mailbox Configuration: In der Mailbox eines jeden Users soll sich standardmäßig ein “Spam”-Ordner befinden, in die ein passendes Sieve-Filterskript verdächtige E-Mails verschieben soll.

Mail Plugins: Hier werden die Details zu den Erweiterungen “sieve”, “quota” und “imapsieve” definiert. Das Script unter “sieve_before” wird für alle User (unabhängig von den eigenen Einstellungen) immer ausgeführt. Es hat die Aufgabe, durch Rspamd markierte Mails in den Spam-Ordner zu verschieben. “sieve_dir” definiert das Schema für den Ort, an dem benutzerdefinierte Scripts abgelegt werden. Das aktive Skript eines Nutzers soll jeweils über den symbolischen Link “active-script.sieve” zugänglich sein. Die “imapsieve” Einstellungen lassen den IMAP-Server Verschiebevorgängezwischen Mailbox-Ordnern erkennen, sodass Rspamd aus einer Neuordnung lernen kann.

SQL-Konfgurationsdatei dovecot-sql.conf

driver=mysql
connect = "host=127.0.0.1 dbname=vmail user=vmail password=vmaildbpass"
default_pass_scheme = SHA512-CRYPT
password_query = SELECT username AS user, domain, password FROM accounts WHERE username = '%n' AND domain = '%d' and enabled = true;
user_query = SELECT concat('*:storage=', quota, 'M') AS quota_rule FROM accounts WHERE username = '%n' AND domain = '%d' AND sendonly = false;
iterate_query = SELECT username, domain FROM accounts where sendonly = false;

Anzupassende Stellen:

Datenbankpasswort “vmaildbpass”

dovecot-sql.conf enthält sensible Datenbank-Zugangsdaten und wird deshalb geschützt:

chmod 440 dovecot-sql.conf

Erklärung

Die Konfigurationsdatei “dovecot-sql.conf” enthält alle SQL-relevanten Einstellungen:

driver: Welcher Datenbank-Treiber soll genutzt werden?
connect: Informationen zur Datenbankverbindung
default_pass_scheme: Standardmäßig angenommenes Hash-Schema, wenn es in der Datenbank nicht explizit angegeben ist, z.B. mit vorangestelltem {SHA512-CRYPT}.
password_query: SQL Query für die Überprüfung des User-Logins. Stimmen Benutzername und Passwort überein? Existiert der Benutzer und ist er aktiviert?
user_query: SQL-Query zum Abholen aller Benutzer-spezifischen Einstellungen. In diesem Fall: Maximales Mailbox-Volumen (“Quota”).
iterate_query: SQL-Query zur Abfrage aller verfügbarer Benutzer. Benutzer, die keine Mails empfangen können (sendonly=true) sind für Dovecot nicht interessant und werden nicht mit ausgegeben.

Globales Sieve-Filterscript für Spam

Unter /var/vmail/sieve/global/ wird das Sieve-Filterscript spam-global.sieve erstellt, das erkannte Spammails in den Unterordner “Spam” jeder Mailbox einsortiert. Rspamd markiert erkannte E-Mails mit einem speziellen Spam-Header, den das Script erkennt. Inhalt von spam-global.sieve:

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

Spam Learning mit Rspamd

Beim Verschieben von Spammails in den Spam-Ordner bzw. dem Herausverschieben falsch beurteilter Mails in den Posteingang soll ein Lernprozess von Rspamd ausgelöst werden, sodass der Filter aus falschen Einschätzungen lernt und so mit der Zeit immer besser wird.

Dazu werden zwei Sieve-Scripts in /var/vmail/sieve/global/ angelegt:

learn-spam.sieve

require ["vnd.dovecot.pipe", "copy", "imapsieve"];
pipe :copy "rspamc" ["learn_spam"];

learn-ham.sieve

require ["vnd.dovecot.pipe", "copy", "imapsieve", "environment", "variables"];
if environment :matches "imap.mailbox" "*" {
set "mailbox" "${1}";
}
if string "${mailbox}" "Trash" {
stop;
}
pipe :copy "rspamc" ["learn_ham"];

Postfix installieren und konfigurieren

Für unseren Postfix-Server benötigen wir nur zwei Pakete: Das Kernpaket “postfix” und die Komponente “postfix-mysql”, die Postfix mit der MySQL-Datenbank kommunizieren lässt.

apt install postfix postfix-mysql

Während der Installation werdet ihr nach der “Allgemeinen Art der Konfiguration” gefragt. Wählt an dieser Stelle “Keine Konfiguration” und beendet den Postfix-Server wieder:

systemctl stop postfix

Im Postfix-Konfigurationsverzeichnis /etc/postfix befinden sich trotz unserer Wahl “Keine Konfiguration” ein paar Konfigurationsdateien, die zunächst entfernt werden:

cd /etc/postfix
rm -r sasl
rm master.cf main.cf.proto master.cf.proto

Legt dann folgende Dateien im Verzeichnis /etc/postfix an:

main.cf

##
## Netzwerkeinstellungen
##
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
inet_interfaces = 127.0.0.1, ::1, 5.1.76.152, 2a00:f820:417::7647:b2c2
myhostname = mail.mysystems.tld
##
## Mail-Queue Einstellungen
##
maximal_queue_lifetime = 1h
bounce_queue_lifetime = 1h
maximal_backoff_time = 15m
minimal_backoff_time = 5m
queue_run_delay = 5m
##
## TLS Einstellungen
###
tls_preempt_cipherlist = yes
tls_ssl_options = NO_COMPRESSION
tls_high_cipherlist = EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA
### Ausgehende SMTP-Verbindungen (Postfix als Sender)
smtp_tls_security_level = dane
smtp_dns_support_level = dnssec
smtp_tls_policy_maps = mysql:/etc/postfix/sql/tls-policy.cf
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_ciphers = high
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
### Eingehende SMTP-Verbindungen
smtpd_tls_security_level = may
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_ciphers = high
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_cert_file=/etc/letsencrypt/live/mail.mysystems.tld/fullchain.pem
smtpd_tls_key_file=/etc/letsencrypt/live/mail.mysystems.tld/privkey.pem
##
## Lokale Mailzustellung an Dovecot
##
virtual_transport = lmtp:unix:private/dovecot-lmtp
##
## Spamfilter und DKIM-Signaturen via Rspamd
##
smtpd_milters = inet:localhost:11332
non_smtpd_milters = inet:localhost:11332
milter_protocol = 6
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}
milter_default_action = accept
##
## Server Restrictions für Clients, Empfänger und Relaying
## (im Bezug auf S2S-Verbindungen. Mailclient-Verbindungen werden in master.cf im Submission-Bereich konfiguriert)
##
### Bedingungen, damit Postfix als Relay arbeitet (für Clients)
smtpd_relay_restrictions = reject_non_fqdn_recipient
reject_unknown_recipient_domain
permit_mynetworks
reject_unauth_destination
### Bedingungen, damit Postfix ankommende E-Mails als Empfängerserver entgegennimmt (zusätzlich zu relay-Bedingungen)
### check_recipient_access prüft, ob ein account sendonly ist
smtpd_recipient_restrictions = check_recipient_access mysql:/etc/postfix/sql/recipient-access.cf
### Bedingungen, die SMTP-Clients erfüllen müssen (sendende Server)
smtpd_client_restrictions = permit_mynetworks
check_client_access hash:/etc/postfix/without_ptr
reject_unknown_client_hostname
### Wenn fremde Server eine Verbindung herstellen, müssen sie einen gültigen Hostnamen im HELO haben.
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks
reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
reject_unknown_helo_hostname
# Clients blockieren, wenn sie versuchen zu früh zu senden
smtpd_data_restrictions = reject_unauth_pipelining
##
## Restrictions für MUAs (Mail user agents)
##
mua_relay_restrictions = reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_mynetworks,permit_sasl_authenticated,reject
mua_sender_restrictions = permit_mynetworks,reject_non_fqdn_sender,reject_sender_login_mismatch,permit_sasl_authenticated,reject
mua_client_restrictions = permit_mynetworks,permit_sasl_authenticated,reject
##
## Postscreen Filter
##
### Postscreen Whitelist / Blocklist
postscreen_access_list = permit_mynetworks
cidr:/etc/postfix/postscreen_access
postscreen_blacklist_action = drop
# Verbindungen beenden, wenn der fremde Server es zu eilig hat
postscreen_greet_action = drop
### DNS blocklists
postscreen_dnsbl_threshold = 2
postscreen_dnsbl_sites = zen.spamhaus.org*2
postscreen_dnsbl_action = drop
##
## MySQL Abfragen
##
virtual_alias_maps = mysql:/etc/postfix/sql/aliases.cf
virtual_mailbox_maps = mysql:/etc/postfix/sql/accounts.cf
virtual_mailbox_domains = mysql:/etc/postfix/sql/domains.cf
local_recipient_maps = $virtual_mailbox_maps
##
## Sonstiges
##
### Maximale Größe der gesamten Mailbox (soll von Dovecot festgelegt werden, 0 = unbegrenzt)
mailbox_size_limit = 0
### Maximale Größe eingehender E-Mails in Bytes (50 MB)
message_size_limit = 52428800
### Keine System-Benachrichtigung für Benutzer bei neuer E-Mail
biff = no
### Nutzer müssen immer volle E-Mail Adresse angeben - nicht nur Hostname
append_dot_mydomain = no
### Trenn-Zeichen für "Address Tagging"
recipient_delimiter = +

Anzupassen:

inet_interfaces: IP-Adressen 5.1.76.152, 2a00:f820:417::7647:b2c2 müssen durch eigene IPv4- (und optional IPv6)-Adresse ersetzt werden.
myhostname: Ersetzen durch eigenen Hostnamen
smtpd_tls_cert_file: Pfad zur Zertifikatsdatei
smtpd_tls_key_file: Pfad zur Zertifikatsdatei

Wichtiger Hinweis für Hetzner CX- vServer Kunden:

Die CX-vServer-Modelle von Hetzner haben ihre öffentliche IP-Adresse nicht direkt an der Netzwerkschnittstelle anliegen. Wenn ihr ein “ip addr” ausführt, seht ihr statt der öffentlichen IP-Adresse eine private Adresse. Das liegt daran, dass Hetzner die öffentliche Adresse auf die private Adresse “NATet”. (Mehr dazu unter “Warum hat meine VM die IP 172.31.1.100?”. Verwendet in der Postfix-Konfiguration und allen übrigen Konfigurationen also nicht die öffentliche Adresse, sondern die private!

Wenn der Mailserver (entgegen meiner Empfehlung) nicht einen “mail.domain.tld” Hostnamen hat, sondern unter dem Domainnamen läuft (domain.tld), muss zur Konfiguration eine Zeile mit

mydestination =

(ohne Inhalt nach dem “=”) hinzugefügt werden, sonst werden E-Mails an der falschen Stelle gespeichert.

Erklärung

Netzwerkeinstellungen:

mynetworks: Anfragen von diesen IP-Adressen / aus diesen IP-Adressbereichen werden von Postfix gesondert behandelt (Verwendung für “mynetworks” in den Restrictions). Üblicherweise werden hier die *lokalen Adressbereiche und IP-Adressen aus dem eigenen Netz eingetragen.
inet_interfaces: Auf diesen IP-Adressen soll Postfix seine Ports öffnen. Die IP-Adressen müssen an den eigenen Server angepasst werden.
myhostname: Der Hostname des Mailservers, wie er bei der Mailverarbeitung genutzt werden soll.

Mail-Queue Einstellungen:

E-Mails in Postfix werden “gequeued”, d.h. in eine Warteschlange eingetragen, die regelmäßig abgearbeitet wird. Wenn Mails nicht zustellbar sind, verbleiben sie eine gewisse Zeit in der Queue, bis ihre Lebenszeit abgelaufen ist, und sie aus der Queue entfernt werden. Der Absender der E-Mail bekommt dann eine entsprechende Nachricht, in der er über die Unzustellbarkeit informiert wird.

maximal_queue_lifetime: Lebensdauer einer normalen Nachricht in der Queue. Wenn eine E-Mail innerhalb einer Stunde nicht zugestellt werden konnte, wird sie aus der Queue entfernt und der Absender benachrichtigt.
bounce_queue_lifetime: Lebensdauer einer Unzustellbarkeits-Benachrichtigung in der Queue.
maximal_backoff_time: Maximale Zeit, die verstreichen darf, bis für eine E-Mail ein neuer Zustellversuch gestartet wird.
minimal_backoff_time: Zeit, die mindestens verstrichen sein muss, bis ein neuer Zustellversuch gestartet wird.
queue_run_delay: Intervall, in dem die Queue nach nicht zustellbaren E-Mails durchsucht wird.

TLS-Einstellungen:

Kompression wird abgeschaltet und (wie bei Dovecot) eine Cipherlist vorgegeben, sodass die bestmögliche Verschlüsselung zwischen Client und Server genutzt wird. Im ersten Teilabschnitt werden die “smtp”-spezifischen TLS-Einstellungen festgelegt – d.h. die Einstellungen, die Postfix als sendenden Kommunikationspartner (Mail-Client) betreffen.

smtp_tls_security_level: Standard-TLS-Policy, wenn sie in der Datenbank für die Empfängerdomain nicht anders spezifiziert wurde: “dane” kontrolliert zunächst, ob für den Empfängerserver ein TLSA-Eintrag (DANE) im DNS vorliegt. Wenn das der Fall ist, wird eine verschlüsselte Verbindung erzwungen und das vorgezeigte Serverzertifikat mittels TLSA-Eintrag verifiziert. Sollte kein TLSA-Eintrag verfügbar sein, fällt Postfix in die Plicy “may” zurück und verschlüsselt nur, wenn der andere Server das unterstützt. Zertifikate werden dabei nicht validiert. Sollten vorhandene TLSA-Einträge ungültig sein, wird stattdessen die “encrypt” Policy genutzt, welche zwar zwingend Verschlüsselt, aber Zertifikate ebenfalls nicht validiert. Mehr zu den TLS-Policies folgt später.
smtp_dns_support_level: DNSSEC-gesicherte DNS-Lookups aktiveren und nutzen, falls möglich
smtpd_tls_policy_maps: Verweist auf die SQL-Queries, mit denen Empfängerdomain-spezifische TLS-Einstellungen geladen werden
smtp_tls_protocols: SSL v2 und v3 werden deaktiviert.

Nun zum zweiten TLS-Block: Dieser gilt für eingehende Verbindungen. Sowohl für andere Server, als auch Mailclients. Wieder werden SSL v2 und 3 deaktiviert und eine starke Cipherlist ausgewählt. Eingehende Verbindungen können verschlüsselt sein, müssen aber nicht.

LMTP-Service:

“virtual_transport” übermittelt verarbeitete, eingehende E-Mails an den LMTP-Service von Dovecot, der sich dann um die Einordnung der Mail in die passende Mailbox kümmert.

Spamfilter und DKIM-Signaturen via Rspamd:

Dieser Abschnitt definiert den Rspam-Daemon als Milter für ein- und ausgehende E-Mails. Eingehende E-Mails werden durch Rspamd auf ihre Seriosität geprüft - ausgehende werden mit einem DKIM-Schlüssel signiert.

Server Restrictions:

Die Blöcke unter “Server restrictions” sind besonders wichtig für die Sicherheit des Mailservers. Falsch eingestellt erlauben sie den unberechtigten Versand von E-Mails (Stichwort “Open Relay”). Der Mailserver wird dann als Spam-Schleuder missbraucht und landet sehr schnell auf einer Blacklist. Damit das nicht passiert, sollten die Restrictions (Beschränkungen) sorgfältig eingestellt und mit einem passenden Open Relay Detektor überprüft sein.

Die Restrictions werden in Leserichtung nacheinander abgearbeitet. Am Ende jeder Verarbeitung steht immer ein “permit” oder “reject”. Für das bessere Verständnis ein Beispiel:

smtpd_relay_restrictions = reject_non_fqdn_recipient
reject_unknown_recipient_domain
permit_mynetworks
reject_unauth_destination

“smtpd_relay_restrictions” bestimmt die Bedingungen, unter der Postfix als Mail-Relay (“Vermittlungsstelle”) arbeitet. Unser Postfix soll nur in drei Fällen auf eingehende E-Mails reagieren:

Wenn ein Mailclient eine E-Mail via Postfix ins Internet schicken will
Wenn ein fremder Mailserver eine E-Mail an unseren Postfix schickt
Wenn vom Mailserver selbst aus eine Mail verschickt werden soll

Um den ersten Fall wird sich in der master.cf Datei gekümmert. Dort werden die Relay Restrictions im Submission-Bereich so überschrieben, dass Mailclients nicht am freien Versenden gehindert werden. Aktuell interessieren daher nur die letzten beiden Anfrage-Typen. Die erste Zeile der Restriction lautet “reject_non_fqdn_recipient”. Sollte die Empfängeradresse keine vollwertige E-Mail Adresse sein, wird die Anfrage an Postfix direkt mit einem “reject” abgewiesen. Alle anderen Checks finden dann nicht mehr statt. Das führt dazu, dass Postfix eine Weiterverarbeitung nur akzeptiert, wenn die zu verarbeitende E-Mail einen gültigen Empfänger hat. Ähnliches gilt für “reject_unknown_recipient_domain”: Wenn die Empfängerdomain keinen gültigen MX- oder A-Eintrag im DNS hat (und der Zielserver damit nicht feststeht), wird die E-Mail abgelehnt.

Die darauf folgende Zeile enthält die “Restriction” “permit_mynetworks”. Wenn der Anfragesteller lokal ist (bzw. seine IP in “mynetworks” vermerkt ist), wird er mit einem “permit” durchgewunken und die E-Mail wird weiter verarbeitet. Weitere Checks finden dann nicht statt. Sollte er nicht in mynetworks vermerkt sein, wird der letzte Check durchgeführt: “reject_unauth_destination” kann nur bestanden werden, wenn die zu verarbeitende E-Mail an eine Empfängeradresse dieses Mailsystems geht. Sollte bis zum Ende der restriction-Definition noch kein “permit” oder “reject” ausgelöst worden sein, wird automatisch ein “permit” ausgelöst und die jeweilige Aktion erlaubt.

Alle anderen Restriction-Definitionen funktionieren ähnlich: Die Kriterien werden nacheinander überprüft. Beginnt ein Kriterium mit einem “reject_”, wird bei Zutreffen ein “reject” ausgelöst, beginnt es mit einem “permit”, wird ein “permit” ausgelöst. In beiden Fällen werden die nachfolgenden Kriterien nicht mehr überprüft.

smtpd_relay_restrictions: Kriterien, die überprüft werden, wenn Anfragen am Postfix-Server eintreffen (Von fremden Mailservern oder vom eigenen Server aus, z.B. via sendmail)
smtpd_recipient_restrictions: Kriterien, die zusätzlich zu den relay_restrictions geprüft werden. Nur bei bestehen der Checks wird eine E-Mail auf dem lokalen System angenommen und an die Empfänger-Mailbox geschickt. An dieser Stelle wird über eine SQL-Abfrage nachgefragt, ob ein bestimmter Empfänger E-Mails empfangen können soll (=> Siehe Option in der Datenbank, Accounts nur zum Versenden freizuschalten).
smtpd_client-restrictions: Kriterien, auf die hin andere Server überprüft werden, wenn Kontakt zum Postfix-Server hergestellt wird. (Müssen gültigen Hostnamen und Reverse-DNS-Eintrag haben)
smtpd_helo_restrictions: Fremde Server müssen zu Beginn ihren gültigen Hostnamen nennen.
smtpd_data_restrictions: Ungeduldige Server sind oft Spammer.

Postscreen Filter:

Der Postscreen-Filter ist ein mächstiges Werkzeug, um Spammer-Server zu blockieren. Bevor ein fremder Server überhaupt eine E-Mail zustellen kann, überprüft Postscreen einige Merkmale des sendenden Servers und kann in den meisten Fällen zuverlässig zwischen gutem und bösen Server unterscheiden.

postscreen_access_list: In der Datei /etc/postfix/postscreen_access können Ausnahmen für den Postscreen-Filter definiert werden.
DNS Blocklist: Postscreen kann anhand von Blacklists / Blocklists entscheiden, ob von einer bestimmten IP-Adresse häufig Spam ausgeht. Dazu werden die bekannten Blocklists unter “dnsbl_sites” befragt. Die zahl hinter dem Stern * ist dabei eine Gewichtung. Besonders zuverlässig arbeitende Blacklists bekommen eine höhere Gewichtung, damit der Schwellwert “dnsbl_threshold” schneller erreicht ist. Sobald der Schwellwert bei einem Server überschritten wird, wird die Verbindung abgebrochen.

Vorsicht mit der zen.spamhaus.org-Blocklist! Spamhaus lässt Anfragen aus dem Google DNS nicht zu. Installiert am besten einen eigenen DNS-Resolver, um dem Problem aus dem Weg zu gehen (daher die Empfehlung, Unbound zu installieren!)

MySQL-Abfragen:

Hier sind die Pfade zu den übrigen SQL-Dateien angegeben, die Postfix benötigt, um Daten aus der Datenbank abfragen zu können.

master.cf

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (no) (never) (100)
# ==========================================================================
###
### Postscreen-Service: Prüft eingehende SMTP-Verbindungen auf Spam-Server
###
smtp inet n - y - 1 postscreen
-o smtpd_sasl_auth_enable=no
###
### SMTP-Daemon hinter Postscreen.
###
smtpd pass - - y - - smtpd
###
### dnsblog führt DNS-Abfragen für Blocklists durch
###
dnsblog unix - - y - 0 dnsblog
###
### tlsproxy gibt Postscreen TLS support
###
tlsproxy unix - - y - 0 tlsproxy
###
### Submission-Zugang für Clients: Für Mailclients gelten andere Regeln, als für andere Mailserver (siehe smtpd_ in main.cf)
###
submission inet n - y - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_sasl_type=dovecot
-o smtpd_sasl_path=private/auth
-o smtpd_sasl_security_options=noanonymous
-o smtpd_client_restrictions=$mua_client_restrictions
-o smtpd_sender_restrictions=$mua_sender_restrictions
-o smtpd_relay_restrictions=$mua_relay_restrictions
-o milter_macro_daemon_name=ORIGINATING
-o smtpd_sender_login_maps=mysql:/etc/postfix/sql/sender-login-maps.cf
-o smtpd_helo_required=no
-o smtpd_helo_restrictions=
-o cleanup_service_name=submission-header-cleanup
###
### Weitere wichtige Dienste für den Serverbetrieb
###
pickup unix n - y 60 1 pickup
cleanup unix n - y - 0 cleanup
qmgr unix n - n 300 1 qmgr
tlsmgr unix - - y 1000? 1 tlsmgr
rewrite unix - - y - - trivial-rewrite
bounce unix - - y - 0 bounce
defer unix - - y - 0 bounce
trace unix - - y - 0 bounce
verify unix - - y - 1 verify
flush unix n - y 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - y - - smtp
relay unix - - y - - smtp
showq unix n - y - - showq
error unix - - y - - error
retry unix - - y - - error
discard unix - - y - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - y - - lmtp
anvil unix - - y - 1 anvil
scache unix - - y - 1 scache
###
### Cleanup-Service um MUA header zu entfernen
###
submission-header-cleanup unix n - n - 0 cleanup
-o header_checks=regexp:/etc/postfix/submission_header_cleanup

Die /etc/postfix/master.cf Datei will ich euch nur im Groben erklären. Wichtig zu wissen ist, dass hier die Definition und Konfiguration der verschiedenen Postfix-Dienste wie z.B. postscreen, smtpd und smtp passiert. Gut zu erkennen ist, dass über ein -o weitere Parameter an einen Dienst übergeben werden. So beispielsweise beim Submission-Dienst, der auf Port 587 für die SMTP-Kommunikation mit den Mailclients bereitsteht: Die hier angegebenen Einstellungen z.B. zu smtpd_relay_restrictions überschreiben die Einstellungen in der main.cf – allerdings nur für diesen einen spezifischen Dienst! Ein gutes Beispiel ist die Einstellung smtpd_tls_security_level=encrypt, die im Submission-Block steht. In der Main.cf hatten wir hier “may” definiert, um keine Server auszuschließen, die TLS nicht beherrschen. Da smtpd-Einstellungen aber sowohl für andere Server als auch für Mailclient gelten, wäre damit auch zu den Mailclients gesagt: “Ihr könnt verschlüsselte Verbindungen herstellen – müsst aber nicht”. Das wollen wir selbstverständlich nicht! Mailclients sollen eine verschlüsselte Verbindung herstellen müssen! Deshalb wird die smtpd-Einstellung speziell für den Submission-Dienst mithilfe der -o Option überschrieben und auf “encrypt” gesetzt.

Für besseren Datenschutz wird der “Received”-Header (+ weitere Datenschutz-relevante Header) bei eingehenden E-Mails entfernt, wenn sie über den Submission-Port eintreffen. Die meisten E-Mail-Clients senden ihren Namen und die Version mit. Zusätzlich vermerkt Postfix bei eingehenden E-Mails, von welcher IP-Adresse die E-Mail stammt. Auf diese Informationen können wir verzichten, deshalb werden sie mithilfe eines kleinen zusätzlichen Dienstes submission-header-cleanup (am Ende der Konfiguration) aus der E-Mail gelöscht. Im Submission-Bereich wird via cleanup_service_name festgelegt, dass bei eingehenden Mails auf dem Submission-Port (wird nur von Mailclients benutz) der Filter anzuwenden ist. Die Filterregeln befinden sich in der Datei /etc/postfix/submission_header_cleanup

Header Cleanup Regeln

Unter /etc/postfix/submission_header_cleanup wird eine Datei mit folgendem Inhalt angelegt:

### Entfernt Datenschutz-relevante Header aus E-Mails von MTUAs
/^Received:/ IGNORE
/^X-Originating-IP:/ IGNORE
/^X-Mailer:/ IGNORE
/^User-Agent:/ IGNORE

SQL-Konfiguration

Neben der Haupt-Konfiguration main.cf und der Service-Konfiguration master.cf werden noch ein paar Konfigurationsdateien innerhalb des Unterverzeichnisses sql/ angelegt, die die SQL-Queries für die Datenabfragen an die Datenbank enthalten:

mkdir /etc/postfix/sql && cd $_

Erstellt dann die folgenden Konfigurationsdateien mit dem zugehörigen Inhalt:

accounts.cf

user = vmail
password = vmaildbpass
hosts = 127.0.0.1
dbname = vmail
query = select 1 as found from accounts where username = '%u' and domain = '%d' and enabled = true LIMIT 1;

aliases.cf

user = vmail
password = vmaildbpass
hosts = 127.0.0.1
dbname = vmail
query = select concat(destination_username, '@', destination_domain) as destinations from aliases where source_username = '%u' and source_domain = '%d' and enabled = true;

domains.cf

user = vmail
password = vmaildbpass
hosts = 127.0.0.1
dbname = vmail
query = SELECT domain FROM domains WHERE domain='%s'

recipient-access.cf

user = vmail
password = vmaildbpass
hosts = 127.0.0.1
dbname = vmail
query = select if(sendonly = true, 'REJECT', 'OK') AS access from accounts where username = '%u' and domain = '%d' and enabled = true LIMIT 1;

sender-login-maps.cf

user = vmail
password = vmaildbpass
hosts = 127.0.0.1
dbname = vmail
query = select concat(username, '@', domain) as 'owns' from accounts where username = '%u' AND domain = '%d' and enabled = true union select concat(destination_username, '@', destination_domain) AS 'owns' from aliases where source_username = '%u' and source_domain = '%d' and enabled = true;

tls-policy.cf

user = vmail
password = vmaildbpass
hosts = 127.0.0.1
dbname = vmail
query = SELECT policy, params FROM tlspolicies WHERE domain = '%s'

Vergesst nicht, vmaildbpass in jeder der Dateien durch euer eigenes Passwort zu ersetzen!

Alle SQL-Konfgurationsdateien in /etc/postfix/sql werden vor dem Zugriff durch unberechtigte User geschützt:

chmod -R 640 /etc/postfix/sql

Weitere Postfix-Konfigurationsdateien

Außerdem gibt es noch zwei weitere Dateien in /etc/postfix, die zunächst leer bleiben können:

touch /etc/postfix/without_ptr
touch /etc/postfix/postscreen_access

Die Datei without_ptr kann Einträge wie den folgenden beinhalten:

1.2.3.3 OK

Der Server mit dem IP 1.2.3.3 muss dann keinen gültigen PTR-Record mehr besitzen und wird trotzdem akzeptiert. Die without_ptr-Datei muss nach jeder Änderung in eine Datenbankdatei umgewandelt und Postfix neu geladen werden:

postmap /etc/postfix/without_ptr
systemctl reload postfix

Im Moment reicht es aus, einfach nur eine leere Datenbankdatei zu generieren:

postmap /etc/postfix/without_ptr

Die Datei postscreen_access kann Ausnahme-IP-Adressen enthalten, die nicht von Postscreen überprüft werden sollen. Der Inhalt könnte beispielsweise so aussehen:

1.2.3.3 permit

Ein Server mit der IP-Adresse “1.2.3.3” wird dann nicht mehr von Postscreen kontrolliert. Hängt man statt des “permit” ein “reject” an, wird der Server mit der jeweiligen IP-Adresse auf jeden Fall von Postscreen blockiert.

Zum Schluss wird einmal

newaliases

ausgeführt, um die Alias-Datei /etc/aliases.db zu generieren, die Postfix standardmäßig erwartet.

Rspamd

Da die Rspamd-Pakete für Debian nicht besonders aktuell sind, nutzen wir an dieser Stelle das Debian-Repository des Rspamd-Projekts:

apt install -y lsb-release wget
wget -O- https://rspamd.com/apt-stable/gpg.key | apt-key add -
echo "deb http://rspamd.com/apt-stable/ $(lsb_release -c -s) main" > /etc/apt/sources.list.d/rspamd.list
echo "deb-src http://rspamd.com/apt-stable/ $(lsb_release -c -s) main" >> /etc/apt/sources.list.d/rspamd.list

Paketquellen aktualisieren und Rspamd installieren

apt update
apt install rspamd

Rspamd stoppen:

systemctl stop rspamd

Grundkonfiguration

Die Konfiguration von Rspamd wird im Verzeichnis /etc/rspamd/local.d/ abgelegt. Die folgenden Konfigurationsdateien werden darin erstellt:

/etc/rspamd/local.d/options.inc: Netzeinstellungen. Definition des lokalen Netzes und des zu nutzenden DNS-Resolvers.

local_addrs = "127.0.0.0/8, ::1";
dns {
nameserver = ["127.0.0.1:53:10"];
}

/etc/rspamd/local.d/worker-normal.inc: Einstellungen für den normalen Rspamd Worker.

bind_socket = "localhost:11333";
### Anzahl der zu nutzenden Worker. Standard: Anzahl der virtuellen Prozessorkerne.
# count = 1

/etc/rspamd/local.d/worker-controller.inc: Einstellung des Worker controllers: Passwort für den Zugriff via Weboberfläche, z.B.:

password = "$2$qecacwgrz13owkag4gqcy5y7yeqh7yh4$y6i6gn5q3538tzsn19ojchuudoauw3rzdj1z74h5us4gd3jj5e8y";

Der Passworthash ("$2$ …") wird via

rspamadm pw

(…dann gewünschtes Passwort eingeben) generiert und muss in der Konfigurationsdatei angepasst werden!

/etc/rspamd/local.d/worker-proxy.inc: Worker Proxy (Milter-Modul für Postfix)

bind_socket = "localhost:11332";
milter = yes;
timeout = 120s;
upstream "local" {
default = yes;
self_scan = yes;
}

/etc/rspamd/local.d/logging.inc: Error logging

type = "file";
filename = "/var/log/rspamd/rspamd.log";
level = "error";
debug_modules = [];

Milter Headers /etc/rspamd/local.d/milter_headers.conf

use = ["x-spamd-bar", "x-spam-level", "authentication-results"];
authenticated_headers = ["authentication-results"];

Redis für den Bayes’schen Filter nutzen: /etc/rspamd/local.d/classifier-bayes.conf

backend = "redis";

DKIM Signing

Rspamd übernimmt auch das Signieren von ausgehenden E-Mails. Damit signiert werden kann, muss zunächst ein Signing Key generiert werden. Der Parameter -s 2017 gibt den sogenannten Selektor an - einen Namen für den Key (hier das Erstellungsjahr).

mkdir /var/lib/rspamd/dkim/
rspamadm dkim_keygen -b 2048 -s 2017 -k /var/lib/rspamd/dkim/2017.key > /var/lib/rspamd/dkim/2017.txt
chown -R _rspamd:_rspamd /var/lib/rspamd/dkim
chmod 440 /var/lib/rspamd/dkim/*

Zum Signing Key (/var/lib/rspamd/dkim/2017.key) gehört ein dazu passender Public Key, welcher in Form eines vorbereiteten DNS-Records in der Datei /var/lib/rspamd/dkim/2017.txt liegt.

DKIM Record ausgeben lassen:

cat /var/lib/rspamd/dkim/2017.txt

Die Ausgabe sieht z.B. so aus:

2017._domainkey IN TXT ( "v=DKIM1; k=rsa; "
"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2/al5HqXUpe+HUazCr6t9lv2VOZLR369PPB4t+dgljZQvgUsIKoYzfS/w9NagS32xZYxi1dtlDWuRfTU/ahHO2MYzE0zHE4lMfwb6VkNCG+pM6bAkCwc5cFvyRygwxAPEiHAtmtU5b0i9LY25Z/ZWgyBxEWZ0Wf+hLjYHvnvMqewPsduUqKVjDOdUqeBb1VAu3WFErOAGVUYfKqFX"
"+yfz36Alb7/OMAort8A5Vo5t5k0vxTHzkYYg5KB6tLS8jngrNucGjyNL5+k0ijPs3yT7WpTGL3U3SEa8cX8WvOO1fIpWQz4yyZJJ1Mm62+FskSc7BHjdiMHE64Id/UBDDVjxwIDAQAB"
) ;

Der Werte-Abschnitt des Records (beginnend mit v=DKIM1 bis zum Ende der Zeichenkolonne - hier AQAB) muss in einen neuen DNS-Record gepflanzt werden. Dabei werden Zeilenumbrüche und Anführungsstriche entfernt. Je nach DNS-Hoster muss ein neuer Eintrag geringfügig anders formatiert werden. Ich habe den Schritt im Screenshot beispielhaft für den Hoster Core-Networks.de und meine Domain “security-enforced.de” (an Stelle von mysystems.tld) durchgeführt:

core-networks.de Screenshot mit DKIM Record

Wichtig: Der Selektor “2017” wird im DNS-Record zusammen mit “._domainkey” als Name verwendet! Der DKIM-Record muss für jede verwendete Domain (domain2.tld, domain2.tld) im jeweiligen Zonefile erstellt werden!

Sollte der Record vom DNS-Hoster nicht akzeptiert werden, hilft es in einigen Fällen, die Schlüssellänge von 2048 Bit auf 1024 Bit zu reduzieren. Dazu das rspamadm dkim_keygen Kommando nochmals mit -b 1024 statt mit -b 2048 ausführen.

Der erzeugte DKIM-Key und der verwendete Selektor werden in der Konfigurationsdatei /etc/rspamd/local.d/dkim_signing.conf angegeben:

path = "/var/lib/rspamd/dkim/$selector.key";
selector = "2017";
### Enable DKIM signing for alias sender addresses
allow_username_mismatch = true;

Diese Konfiguration wird in die Datei /etc/rspamd/local.d/arc.conf kopiert, sodass das ARC-Modul korrekt arbeiten kann. Es greift auf dieselben Einstellungen zurück:

cp -R /etc/rspamd/local.d/dkim_signing.conf /etc/rspamd/local.d/arc.conf

Redis als Cache und Key-Value Store für Rspamd-Module

Rspamd verwendet Redis als Cache. Die Installation und Einrichtung ist trivial:

apt install redis-server

/etc/rspamd/local.d/redis.conf

servers = "127.0.0.1";

Rspamd starten

Rspamd kann nun gestartet werden:

systemctl start rspamd

Nginx Proxy für Rspamd Weboberfläche (optional)

Für den bequemen und sicheren Zugriff auf die Rspamd-Weboberfläche kann dieser ein Nginx HTTP-Proxy vorgeschaltet werden. Nginx kümmert sich dann um die Absicherung der Verbindung via HTTPS. Wer nur selten auf die Rspamd-Weboberfläche zugreift, kann auf diesen Schritt verzichten und stattdessen auch über einen SSH-Tunnel auf das Interface zugreifen (siehe unten).

Installation:

apt install nginx
nano /etc/nginx/sites-available/mail.mysystems.tld

Inhalt der neuen Konfigurationsdatei /etc/nginx/sites-available/mail.mysystems.tld

server {
listen 80;
listen [::]:80;
listen 443 ssl http2;
listen [::]:443 ssl http2;
ssl_certificate /etc/letsencrypt/live/mail.mysystems.tld/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mail.mysystems.tld/privkey.pem;
server_name mail.mysystems.tld;
root /var/www/default;
if ($ssl_protocol = "") {
return 301 https://$server_name$request_uri;
}
location /rspamd/ {
proxy_pass http://localhost:11334/;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}

Anzupassen:

ssl_certificate: Pfad zu Zertifikat
ssl_certificate_key: Pfad zu Zertifikat
server_name

Seite aktivieren, Konfiguration testen und Nginx neu laden:

ln -s /etc/nginx/sites-available/mail.mysystems.tld /etc/nginx/sites-enabled/mail.mysystems.tld
nginx -t
systemctl reload nginx

Apache Proxy für Rspamd Weboberfläche (optional, nicht überprüft!)

Apache2 installieren:

apt install apache2

Proxy-Modul aktivieren und neu starten:

a2enmod proxy
a2enmod proxy_http
systemctl restart apache2

Konfiguration /etc/apache2/sites-available/mailserver.conf:

<VirtualHost *:80>
ServerName mail.mysystems.tld
Redirect / https://mail.mysystems.tld/
</VirtualHost>
<VirtualHost *:443>
ServerName mail.mysystems.tld
ServerPath /
DocumentRoot /var/www
DirectoryIndex index.html
SSLEngine on
SSLHonorCipherOrder on
SSLCertificateFile /etc/letsencrypt/live/mail.mysystems.tld/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mail.mysystems.tld/privkey.pem
###
### Rspamd
###
RewriteEngine on
RewriteRule ^/rspamd$ /rspamd/ [R]
ProxyPreserveHost On
ProxyPass /rspamd http://localhost:11334/
ProxyPassReverse /rspamd http://localhost:11334/
</VirtualHost>

Neue Konfiguration aktivieren und Apache neu laden:

a2ensite mailserver
systemctl reload apache2

Weboberfläche aufrufen

Unter https://mail.mysystems.tld/rspamd/ ist die Rspamd-Weboberfläche nun erreichbar. Als Passwort wird das weiter oben erzeugte Passwort für die Weboberfläche verwendet.

Rspamd gibt im Log und auf der Weboberfläche Fehler aus: "/var/lib/rspamd/ [...]: map file is unavailable for reading". Dabei handelt es sich im einen Bug, der ignoriert werden kann. (Siehe auch: https://github.com/vstakhov/rspamd/issues/1474)

Via SSH-Tunnel mit der Weboberfläche verbinden (Alternative)

Statt über Nginx kann man auch mithilfe eines SSH-Tunnels eine sichere Verbindung zur Rspamd-Weboberfläche aufbauen. Dazu benötigt man auf dem lokalen Rechner allerdings einen SSH-Client. Der SSH-Befehl

ssh -L 8080:localhost:11334 benutzer@mail.mysystems.tld -N

verknüpft den Port des Webinterfaces (11334) mit Port 8080 des lokalen Systems. Im lokalen Webbrowser kann die Oberfläche nun unter http://localhost:8080 erreicht werden. Mit STRG+C wird die Verbindung wieder getrennt.

Rspamd mit bestehenden Spam-E-Mails trainieren (optional)

Wer einige Mails im Maildir-Format (jede E-Mail ist eine Datei) vorliegen hat, kann Rspamd mit über das rspamc-Werkzeug trainieren. Dabei ist es ist vorteilhaft, nicht nur Spammail-Beispiele zu trainieren, sondern auch Beispiele für erwünschte E-Mails. Im folgenden Beispiel wurde das Mailbox-Verzeichnis eines älteren Mailservers importiert:

E-Mails in einem Verzeichnis als Spam antrainieren:

find ./oldserver/var/vmail/mailboxes/*/*/mail/Spam/cur -type f -exec /usr/bin/rspamc learn_spam {} \;

E-Mails in einem Verzeichnis als Ham (harmlos) antrainieren:

find ./oldserver/var/vmail/mailboxes/*/*/mail/cur -type f -exec /usr/bin/rspamc learn_ham {} \;
find ./oldserver/var/vmail/mailboxes/*/*/mail/Sent/cur -type f -exec /usr/bin/rspamc learn_ham {} \;

Auf der Rspamd-Weboberfläche wird nach dem Training eine entsprechend höhere Anzahl an gelernten E-Mails angezeigt.

Domains, Accounts, Aliase und TLS-Policies in Datenbank definieren

Bevor der Mailserver sinnvoll genutzt werden kann, müssen noch Domains und Benutzer im der MySQL-Datenbank registriert werden. Loggt euch wieder auf der MySQL-Kommandozeile ein:

mysql

… und wechselt in die vmail-Datenbank:

use vmail;

Neue Domain anlegen

Damit ein neuer Benutzeraccount oder ein neuer Alias angelegt werden kann, muss die zu nutzende Domain zuvor im Mailsystem bekannt gemacht werden. Postfix verarbeitet nur E-Mails an Domains, die in der “domains”-Tabelle eingetragen sind:

insert into domains (domain) values ('mysystems.tld');

Neuen E-Mail-Account anlegen

Wenn die Benutzerdomain in der Domain-Tabelle angelegt ist, kann ein neuer Benutzeraccount für den Mailserver erstellt werden. Bevor das passende SQL-Kommando eingegeben und abgeschickt wird, wird jedoch zu nächst ein Passwort-Hash des gewünschten Passworts für den Account erzeugt. Mit

doveadm pw -s SHA512-CRYPT

(in der Bash Shell! - Nicht in der MySQL Shell!) kann ein solcher Hash erzeugt werden. Beispiel für einen ausgegebenen Hash:

{SHA512-CRYPT}$6$wHyJsS.doo39xoCu$KI1N4l.Vd0ZWYj5BYLI8AdK7ACwAZaM18gSy7Bko0dG2Hvli4.KfAmLk2ztFVP.R4T7oqiu7clKBehCTc4GGw0

Dieser Hash ist für jedes Passwort einzigartig und ändert sich sogar bei jeder Generierung. Legt den Hash am besten gleich in eurer Zwischenablage oder einem Textdokument ab - ihr benötigt ihn gleich!

Das SQL-Kommando zum Erzeugen eines neuen Accounts lautet:

insert into accounts (username, domain, password, quota, enabled, sendonly) values ('user1', 'mysystems.tld', '{SHA512-CRYPT}$6$wHyJsS[...]', 2048, true, false);

In das “Password”-Feld wird der Hash vollständig eingetragen (hier: gekürzt).

Neuen Alias anlegen

insert into aliases (source_username, source_domain, destination_username, destination_domain, enabled) values ('alias', 'mysystems.tld', 'user1', 'mysystems.tld', true);

… legt einen Alias für den Benutzer “user1@mysystems.tld” an. E-Mails an “alias@mysystems.tld” werden dann an die Mailbox dieses Users zugestellt.

Als Zieladressen können auch E-Mail-Konten auf fremden Servern angegeben werden. Postfix leitet diese E-Mails dann weiter. Dabei kann es allerdings zu Problemen mit SPF-Records kommen – schließlich schickt Postfix unter bestimmten Umständen E-Mails unter fremden Domains, für die er laut SPF-Record nicht zuständig ist. SRS (Sender Rewriting Scheme) ist eine Lösung für dieses Problem. Von Erweiterungen, die schwerwiegende Design-Fehler einer Technik wie SPF korrigieren, halte ich allerdings nicht besonders viel, sodass ich euch empfehle, den SPF-Record (wie oben) auf einem “?all” gestellt zu lassen und auf Weiterleitungen zu fremden Servern möglichst zu verzichten. Aliase von lokalen Adressen auf andere lokale Adressen sind kein Problem.

Wenn ein E-Mail-Verteiler eingerichtet werden soll, werden mehrere Datensätze mit derselben Quelladresse eingerichtet, also z.B. so:

team@domain.tld => user1@domain.tld
team@domain.tld => user2@domain.tld
team@domain.tld => user3@domain.tld

Neue TLS-Policy anlegen (optional)

Mithilfe der TLS Policy-Tabelle kann festgelegt werden, mit welchen Sicherheitsfeatures mit den Mailservern einer bestimmten Domain kommuniziert werden soll. Wenn für die Domain “thomas-leister.de” beispielsweise “dane-only” in “policy” festgelegt wird, wird die Verbindung zu Mailservern dieser Domain nur noch gültig sein, wenn sie DANE-authentifiziert und verschlüsselt ist. Mögliche Policies sind:

none: Keine Verschlüsselung nutzen, auch wenn der andere Mailserver das unterstützt.
may: Verschlüsseln, wenn der andere Server dies unterstützt, aber keine Zertifikatsprüfung (self-signed Zertifikate werden akzeptiert).
encrypt: Zwingend Verschlüsseln, allerdings keine Zertifikatsprüfung (self-signed Zertifikate werden akzeptiert).
dane: Wenn gültige TLSA-Records gefunden werden, wird zwingend verschlüsselt und das Zertifikat mittels DANE verifiziert. Falls ungültige TLSA-Records gefunden werden, wird auf “encrypt” zurückgegriffen. Falls gar keine TLSA-Records gefunden werden, wird “may” genutzt.
dane-only: Nur verschlüsselte Verbindungen. Gültige TLSA-Records für den Hostnamen müssen existieren (DANE)
verify: Nur verschlüsselte Verbindungen + Prüfung der CA. Der Hostname aus dem MX DNS-Record muss im Zertifikat enthalten sein. (Basiert auf Vertrauen in korrekte DNS-Daten)
secure: Nur verschlüsselte Verbindungen + Prüfung der CA. Der andere Mailserver muss (standardmäßig) einen Hostnamen haben, der “.domain.tld” oder nur “domain.tld” entspricht. Dieser Hostname muss im Zertifikat enthalten sein. Auf das DNS wird nicht zurückgegriffen (Sicherheitsvorteil gegenüber “verify). Beispiel: Eine E-Mail an user@web.de soll gesendet werden. Der MX-Mailserver von Web.de dürfte dann nur den Hostnamen “web.de” oder eine Subdomain davon als Hostnamen haben, z.B. mx.web.de. Eine Verbindung zu mx.web.net wäre nicht zulässig.

Für Domains der großen Anbieter wie gmx.de, web.de und der Telekom kann man “secure” wählen. Bei Posteo und Mailbox.org sogar “dane-only”. Für alle Provider, die keine gültigen TLS-Zertifikate einsetzen, kann “encrypt” gewählt werden. Standardeinstellung für alle anderen Mailserver ist “dane” (siehe main.cf der Postfix Config).

Das Feld “params” wird mit zusätzlichen Infos gefüllt, wenn sie für einen Policy-Typ erforderlich sind, z.B. für einen “secure” Eintrag zu GMX:

insert into tlspolicies (domain, policy, params) values ('gmx.de', 'secure', 'match=.gmx.net');

Standardmäßig überprüft Postfix bei “secure” – wie oben bereits erwähnt – ob die Empfängerdomain (gmx.de) im Zertifikat des Zielservers vorhanden ist. Bei GMX (und vielen anderen großen Anbietern) ist das allerdings nicht der Fall: Die Mailserver-Zertifikate von GMX sind nur für gmx.net + Subdomains gültig. Ließe man den Datenbank-Eintrag für GMX ohne weitere Einstellungen auf “secure” stehen, könnten an GMX keine Mails mehr übermittelt werden. Deshalb ist es wichtig, für GMX festzulegen, dass im Zertifikat nicht nach “gmx.de” sondern nach “gmx.net” gesucht werden soll. Das können wir mithilfe des Felds “params” und der “match=…” Zeichenkette tun. Wenn nach mehreren Domains gesucht werden soll, können auch mehrere angegeben werden, z.B. so: “match=.gmx.net:.gmx.ch”. Die zusätzlichen Angaben in “params” sind allerdings nicht für jeden Mailprovider notwendig. GMX ist eine Ausnahme – genauso wie z.B. Yahoo. Ob ihr in “params” einen “match”-String angeben müsst, könnt ihr z.B. über https://de.ssl-tools.net/ herausfinden. Wenn die 2-nd-Level-Domain des Mailservers von der Domain der Mailadressen abweicht, muss ein passender match-String angegeben werden.

Andere Einstellungen wie “dane-only” erfordern keine zusätzlichen Angaben in “params”:

insert into tlspolicies (domain, policy) values ('mailbox.org', 'dane-only');

In diesem Fall wird mit den Mailservern von mailbox.org nur noch DANE-gesichert und verschlüsselt kommuniziert.

Die MySQL-Kommandozeile kann mit einem quit; wieder verlassen werden.

Start all the things!

Euer neuer Mailserver ist jetzt fertig konfiguriert. Zeit für einen ersten Start!

systemctl start dovecot
systemctl start postfix

Wegen des Bugs #877992 startet Postfix nach einem Reboot nicht mehr. Abhilfe schafft folgendes Kommando:

systemctl enable postfix@-

(beachte “-” am Ende!)

Kontrolliert am besten gleich die Logfiles nach auffälligen Fehlern. Ich empfehle das “tail” Tool in einer separaten Terminal-Sitzung. Neue Log-Einträge erscheinen damit sofort auf dem Bildschirm:

tail -f /var/log/syslog

bzw.

tail -f /var/log/mail.log

Wenn ihr hier Fehler entdeckt, seht nach, ob ihr alle erforderlichen Änderungen an den Konfigurationsdateien durchgeführt habt (oder ob sich noch beispielhafte Hashes oder Beispieldomains darin befinden).

Eine Verbindung zum Mailserver herstellen

Eine Verbindung könnt ihr über jeden IMAP-fähigen E-Mail-Client und den folgenden Verbindungsparametern herstellen:

IMAP-Server: mail.mysystems.tld | Port: 143 | STARTTLS (dieser Server gilt auch für domain2 und domain3!)
SMTP-Server: mail.mysystems.tld | Port: 587 | STARTTLS (dieser Server gilt auch für domain2 und domain3!)
(optional Managesieve: mail.mysystems.tld | Port: 4190 | STARTTLS) (auch für domain2 und domain3!)
Benutzername: Die vollständige E-Mail-Adresse
Passwort: Sollte bekannt sein ;-)

Der erste Login kann einige Zeit in Anspruch nehmen!

Mailserver Logindaten für Thunderbird

Spamfilter testen

Schickt einfach eine E-Mail mit dem Text

XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X

an einen Account eures neuen Mailservers. Die E-Mail sollte nicht ankommen und im Rspamd-Webinterface erscheint ein entsprechender rot markierter Eintrag in der History.

Das war’s auch schon! …

Hat dir diese Anleitung geholfen?

Wenn ich dir mit dieser Anleitung helfen konnte, deinen Mailserver aufzusetzen,
ist dir das vielleicht ein paar Euro wert.

Wie du dir sicherlich vorstellen kannst, war es eine Menge Arbeit, diese Anleitung zu erproben und zu formulieren. Daher freue ich mich natürlich riesig über eine Motivationsstütze und finanzielle Hilfe, um Testserver und -Umgebungen bezahlen zu können, oder mir nach getaner Arbeit ein kühles Bier zu leisten.

Wie du mir etwas zukommen lassen kannst, erfährst du hier: Unterstützen

Herzlichen Dank! :-)

Fragen und Antworten

“Danke für die Anleitung. Kann ich mich irgendwie revanchieren?”

Über ein “Dankeschön” via E-Mail freue ich mich, aber z.B. auch über eine kleine Finanzspritze für meinen Blog via Bitcoin, PayPal oder auf anderem Wege. Damit kann ich beispielsweise meine Server bezahlen. Vielleicht magst du diesen Beitrag auch weiterempfehlen? Auch dafür bin ich dankbar :-) => Blog Unterstützen

“Wieso noch eine Mailserver-Anleitung? Es gibt doch schon so viele!”

Tatsächlich kann man den Eindruck haben, zu jedem Linux-Blog gehöre mittlerweile ein E-Mail Tutorial. Natürlich habe ich darüber nachgedacht, ob es überhaupt sinnvoll ist, den Aufwand zu betreiben, und die tausendste Anleitung dazu zu schreiben. Aber natürlich habe ich gute Gründe: Ich bin während meiner ersten Schritte zum eigenen Mailserver fast verzweifelt: Es gibt zwar Unmengen an Mailserver-Anleitungen im Netz, und trotzdem gibt es zu viele How-Tos, die nie wirklich getestet wurden oder schon veraltet sind. Diese Anleitung wurde mehrmals auf einem frisch installierten Debian Server getestet. Ich kann also bis zu einem gewissen Grad garantieren, dass euer Mailserver funktioniert, wenn ihr die Anleitung exakt durcharbeitet. Einige Artikel zum Thema finde ich auch nicht ausführlich genug. Wie Eingangs schon erklärt, geht es mir bei diesem Beitrag auch darum, ein wenig zu erklären, was hier eigentlich passiert. Und nicht zuletzt: Es gibt diese Anleitung, weil ich der Meinung bin, dass es nicht genug geben kann. Jeder Autor erklärt etwas anders, jeder stellt ein leicht verändertes Setup vor. Ich hatte Lust, mein eigenes Setup in diesem Beitrag zu erklären, weil es gut funktioniert.

“Darf ich deine Anleitung übernehmen?”

Nein. Du kannst dir sicherlich vorstellen, dass hinter meiner Anleitung viel Mühe und Arbeit steckt. Ich stelle sie nicht frei zur Verfügung und bitte darum, meinen Text nicht ohne ausdrückliche Zustimmung zu re-publizieren (auch nicht in privaten, aber öffentlich zugänglichen Blogs!). Also ein klares “Nein” zu Copy & Paste + Wiederveröffentlichung. Private, nicht-öffentliche Kopien oder Kopien für den Firmen-internen Gebrauch sind natürlich erlaubt. Es geht mir auch darum, diesen Beitrag nicht auf irgendeinem fremden Blog wiederzufinden, der womöglich sogar noch Geld mit fremden Content verdient. Verlinken ist natürlich absolut erlaubt und ausdrücklich erwünscht ;-)

“Wieso veröffentlichst du deine Anleitung auf deinem Blog und nicht in einem Wiki?”

Weil ich hier die volle Kontrolle habe. Was hier steht, ist in sich konsistent und kein Flickenteppich. In den gängigen Wikis darf dieser Beitrag natürlich gerne ergänzend verlinkt werden.

“Gibt es für dieses neue Mailserver-Setup schon einen Web-Client zur Verwaltung?”

Aktuell ist WebMUM nicht mit dieser Anleitung kompatibel. Solltet ihr das ändern wollen – nur zu. Der Code ist auf GitHub unter der MIT Lizenz frei verfügbar. Ansonsten steht es natürlich jedem frei, selbst ein solches Werkzeug zu entwickeln und vielleicht sogar frei verfügbar zu machen. Im Wesentlichen müssen nur Datensätze erstellt, bearbeitet und gelöscht werden. Das kann man z.B. auch als PHP-Anfänger gut umsetzen.

Andreas Bresch hat übrigens schon ein Webinterface zu dieser Anleitung entwickelt: https://github.com/Andreas-Bresch/vmailManage/

Wie kann ich mit diesem Setup Catch-All Adressen realisieren?

Dazu sind ein paar Änderungen notwendig. Ich habe mich mit der Thematik noch nicht selbst befasst, aber ein Leser hatte hiermit Erfolg:

source_username in aliases Tabelle als nullable (= null bei catchall) konfigurieren. In der MySQL-Kommandozeile:

alter table aliases modify source_username varchar(64) null;
Die Query in aliases.cf anpassen

query = SELECT concat(destination_username, ‘@’, destination_domain) as destinations FROM aliases WHERE source_username =’%u’ and source_domain =’%d’ and enabled = true UNION ALL SELECT concat(destination_username, ‘@’, destination_domain) as destinations FROM aliases WHERE source_username is null and source_domain =’%d’ and enabled = true AND not exists (SELECT id FROM aliases WHERE source_username =’%u’ and source_domain =’%d’ and enabled = true);

Ich habe das nicht getestet!

“Wieso Port 587 und 143 mit STARTTLS?”

Postfix verwendet Port 587 für die Verbindung zu MUAs (Mail User Agents - “Mailprogramme”), weil Port 25 nur für den Transfer der E-Mails zwischen den Servern zuständig sein soll. Während auf Port 25 von jedem Sender E-Mails ohne Authentifizierung empfangen werden können, wird auf Port 587 eine vorherige Authentifizierung des Endnutzers erzwungen. Port 587 wird daher auch als “Submission”-Port bezeichnet und ist üblicherweise in Firewalls freigeschaltet (siehe auch: RFC 6409 Submission). Port 25 hingegen wird beispielsweise in Unternehmensfirewalls und von manchen DSL-Routern blockiert, um das Spam-Problem einzudämmen. Aus einem solchen Netz können dann nur noch E-Mails zum zuständigen Mailserver gesendet werden - nicht mehr an jeden beliebigen Mailserver direkt. Da 587 als “universeller” Port (mit und ohne TLS-Verschlüsselung) definiert wurde, wird hier STARTTLS eingesetzt. Der ehem. “nur-TLS”-Port 465 ist nicht mehr als Standard festgelegt!

Für Dovecot verwende ich ebenfalls einen STARTTLS-Port. Dieser ist als Port 143 in RFC 3501 definiert. Prinzipiell ließe sich zwar als “TLS only” Port der weiterhin spezifizierte “imaps”-Port 993 verwenden, aber aus Gründen der Einheitlichkeit (und weil auch mit STARTTLS Verschlüsselung erzwungen werden kann) habe ich mich für 143 entschieden.

Kurz: Die Ports habe ich aus Abwägungen bezüglich der geltenden IANA-Standards und der Einheitlichkeit gewählt. Durch den Einsatz von STARTTLS entstehen (bei meiner Konfiguration) keine Nachteile.

Häufige Fehler

“fatal: no SASL authentication mechanisms” / “SASL: Connect to private/auth failed: No such file or directory”

Das Problem: Postfix kann Benutzer nicht authentifizieren, weil in /var/spool/postfix/private kein “auth” Socket verfügbar ist. Eigentlich sollte Dovecot diesen Socket bereitstellen. Der Fehler ist also bei Dovecot zu suchen – nicht bei Postfix. Leider hat die Erfahrung gezeigt, dass ein Vertipper nicht zwingend in der Socket-Konfiguration

unix_listener /var/spool/postfix/private/auth {
mode = 0660
user = postfix
group = postfix
}

vorhanden sein muss. Es kommt immer wieder vor, dass der Fehler irgendwo anders in der Dovecot-Konfiguration liegt. Dovecot verschweigt einem dann den Fehler und erstellt den auth-Socket für Postfix nicht. Es lohnt sich in so einem Fall, noch einmal die ganze Dovecot-Konfiguration nach Fehlern abzusuchen.

“5.7.1 Service unavailable; client [1.3.3.7] blocked using zen.spamhaus.org”

Das Problem: Der Mailserver akzeptiert keine E-Mails vom Mailclient und gibt die oben genannte Fehlermeldung zurück.

Das Problem lässt sich sehr einfach lösen, indem statt SMTP-Port 25 der Submission-Port 587 für den Mailversand im Mailclient konfiguriert wird. Auf Port 25 ist eine Blacklist aktiv, welche viele IP-Adressen z.B. aus DSL-Adressbereichen enthält. Diese Einschränkung gilt für Port 587 nicht. Mailclients sollten immer Port 587 für den Versand nutzen.

Mailclient verbindet sich nicht zum Server

Evtl. blockiert der Virenschutz die Verbindung?
Blockiert die Server-Firewall die Verbindung von außen?
Ist die richtige Serveradresse angegeben? (siehe Verbindungseinstellungen oben)

Changelog

(Erstveröffentlichung am 04.08.2017)
29.08.2017
- vmail MySQL user bekommt nur noch “select” Rechte statt allen Rechten
- Überarbeitete Version der master.cf (vor allem submission-Bereich und mehr Dienste laufen nun im chroot für mehr Sicherheit), “mua”-Ergänzung in der main.cf
31.08.2017
- Hinzugefügt: dkim_signing.conf zu arc.conf kopieren, um Fehler cannot load dkim key /var/lib/rspamd/arc/domain.tld.arc.key zu verhindern.
- Hinzugefügt: non_smtpd_milters = inet:localhost:11332, sodass auch e-mails vom Mailserver selbst (lokal erstellt) DKIM signiert werden.
25.10.2017
- Nicht mehr gepflegtes Dovecot Antispam-Plugin ersetzt durch ImapSieve (Änderungen an Dovecot-Config und zusätzliche Sieve Scripts)
27.10.2017
- ADSP records entfernt, stattdessen sollten DMARC-Records eingerichtet werden. Entsprechenden Abschnitt hinzugefügt.
06.11.2017
- Workaround bzgl. Bug #877992 ergänzt.
12.11.2017
- Hinweis zu “Mailman” Weboberfläche ergänzt.
05.12.2017
- Apache2-Konfiguration für Rspamd Proxy hinzugefügt.
19.01.2018
- dovecot.conf: ssl_dh_parameters_length und ssl_protocols entfernt; werden nicht mehr benötigt
- /etc/rspamd/local.d/classifier-bayes.conf hinzugefügt
- Kleinere Style-verbesserungen, Ergänzungen im Text
- Warning bzgl. Ubuntu Server hinzugefügt.
20.01.2018
- Hinweis zu Henrik Halbritters “MailAdmin” hinzugefügt.
22.01.2018
- Dovecot PPA für Ubuntu Server hinzugefügt.
02.02.2018
- tls_preempt_cipherlist = yes zu Postfix main.cf hinzugefügt.
30.03.2018
- Hinweis ergänzt: DKIM-Record muss für alle verwendeten Maildomains im jeweiligen Zonefile hinzugefügt werden!
02.03.2019
- learn-ham gefixt
24.03.2025: Manitu DNSBL entfernt - wird nicht mehr gepflegt

Meine Mastodon-Instanz metalhead.club ist online

thomas.leister@mailbox.org (Thomas Leister) — Tue, 04 Jul 2017 14:00:00 +0200

Seit Freitag, dem 30. Juni ist metalhead.club online - meine eigene Mastodon-Instanz speziell (aber nicht nur!) für Metal-Fans. Zuvor hatte ich meinen Mastodon-Account auf dem Server von Milan. Aus einem spontanen Impuls heraus habe ich mich entschieden, zur Dezentralisierung des Netzwerks beizutragen und ab sofort eine eigene Instanz zu betreiben.

Wie erwartet war der Mastodon-Server schnell aufgesetzt: Domain bestellt, Mastodon via Docker installiert und konfiguriert, TLS-Zertifikate via Let’s Encrypt installiert, und der Server war fertig. Eine offizielle Installationsanleitung dazu findet ihr in der Mastodon-Dokumentation auf GitHub.

Für das Docker-Setup habe ich mich entschieden, weil ich Mastodon zunächst auf einem Server laufen lassen will, den ich sowieso schon in Betrieb habe. Bevor überhaupt klar ist, ob meine Instanz von weiteren Usern genutzt wird, investiere ich nur ungern in einen weiteren VPS. Sollte die Instanz mit der Zeit größer und ressourcenhungriger werden, werde ich den Mastodon-Server auf einen dedizierten, virtuellen Server verlegen. Der große Hype ist allerdings vorüber, sodass ich nicht davon ausgehe, dass meine Instanz stark wächst.

Wer Interesse an Mastodon hat oder seinen Account auf meine Instanz verlegen will, kann sich gerne einen Account auf metalhead.club anlegen. Außer einer E-Mail-Adresse müssen keine weiteren, persönlichen Daten angegeben werden.

Mich findet ihr übrigens als thomas@metalhead.club auf Mastodon und GNUSocial.

Test: Cloudserver-Hoster FarnoX.de

thomas.leister@mailbox.org (Thomas Leister) — Wed, 26 Apr 2017 12:34:00 +0200

Vor kurzem wurde ich via E-Mail auf den Serverhoster FarnoX.de aufmerksam gemacht. Aus eigenem Interesse habe ich ihn mir einmal genauer angesehen und einige Tests auf einem zur Verfügung gestellten Testserver durchgeführt. Kann sich der Hoster gegenüber der Konkurrenz behaupten?

Der Beitrag bildet nur den Stand vom 26. April 2017 ab und ist nicht zwingend auf das aktuelle Datum übertragbar! So kann sich z.B. die Serverleistung inzwischen geändert haben.

Leistung

FarnoX.de bietet jedem Interessenten 7 Tage lang einen kostenlosen Testserver an. Mein Server hatte folgende Konfiguration:

1 vCore
512 MB RAM
10 GB SSD

Für den Benchmark kam die Phoronix Test Suite in Version 7.0.1 zum Einsatz.

CPU

Um einen einfachen Vergleich zu den Servern von Active-servers.com und Servercow machen zu können, habe ich mein sysbench-Kommando aus den jeweiligen Erfahrungsberichten auch auf dem FarnoX-Testserver ausgeführt:

sysbench --test=cpu --num-threads=1 --cpu-max-prime=20000 run

Die benötigte Zeit von 16,4 Sekunden war fast auf hundertstel Sekunden exakt reproduzierbar. Der gemessene Wert ist hervorragend: Bei Servercow erreicht man auf schnellen Hosts nur ca. 22 Sekunden, bei Active-Servers.com zum Zeitpunkt meines letzten Tests ca 25 Sekunden.

Zusätzlich zum Sysbench-Test habe ich auf die bewährte Phoronix-Testsuite zurückgegriffen und einen GZIP-Benchmark (pts/compress-gzip-1.1.0) ausgeführt, anhand dessen sich die CPU-Leistung ebenfalls bewerten lässt:

Ergebnis:
(2 GB file gzip compression): 15.0 Sekunden

RAM

In meinen letzten vServer Testberichten habe ich die RAM-Leistung nicht bewertet. Da die Phoronix-Testsuite aber auch einen RAM-Leistungstest (pts/ramspeed 1.4.0) beinhaltet, habe ich diesen kurzerhand laufen lassen und bin auf folgende Ergebnisse gekommen:

Type: Copy
Benchmark: Integer
Ergebnis: 12701.43 MB/s
Type: Add
Benchmark: Integer
Ergebnis: 14526.63 MB/s

SSD

Die Leistung des SSD-Speichers habe ich mit dem Phoronix-Benchmark pts/fio-1.9.0 getestet.

Benchmark-Einstellungen:

IO Engine: Libaio
Buffered: No
Direct: Yes
Block Size: 4KB

Ergebnisse:

Random Read: 690 MB/s | 172533 IOPS
Random Write: 655 MB/s | 163873 IOPS
Sequential Read: 847.91 MB/s | 211975 IOPS
Sequential Write: 797.91 MB/s | 199474 IOPS

Netzanbindung

Die Leistung der Internetanbindung habe ich mithilfe des starken Tele2 Speedtest-FTP-Servers überprüft (Siehe auch Beitrag: Bandbreite der Internetanbindung auf Linux-Servern via Kommandozeile testen). Um den FTP-Server als Flaschenhals auszuschließen, habe ich gleichzeitig auf meinen Servercow-Sevrern denselben Test ausgeführt.

FarnoX.de garantiert keine Mindestgeschwindigkeit. Auf Nachfragen wurde mir zugesichert, dass in der Praxis 1 GBit/s aber kein Problem sein sollte.

Download:

Die erzielbare Download-Rate ist zwar für Server weniger wichtig als die Upload-Rate, aber trotzdem nicht zu vernachlässigen. Wer will schon lange auf Softwareinstallationen oder größere Uploads auf den Server warten? Die Downlink-Leistung habe ich an mehreren Tagen zu verschiedenen Uhrzeiten mit dem folgenden Kommando getestet:

curl ftp://speedtest.tele2.net/1GB.zip -o /dev/null

Beim Download der 1 GB großen Testdatei konnte ich in den Einzeltests zwischen 16 MBit/s und 800 MBit/s verschiedenste Werte messen. Als Tagesdurchschnitte aus den Einzeltests habe ich folgende Übertragungsgeschwindigkeiten im Download ermittelt:

21. April: Ø 800 MBit/s
22. April: Ø 128 MBit/s
23. April: Ø 464 MBit/s
24. April: Ø 592 MBit/s

Die erreichte Geschwindigkeit war nicht nur an verschiedenen Tagen sehr unterschiedlich, sondern auch von Einzeltest zu Einzeltests. Ob nun gerade viel oder wenig Bandbreite zur Verfügung steht, ist von Sekunde zu Sekunde offenbar sehr verschieden. 1 GBit/s konnte ich annähernd nur selten erreichen.

Upload:

Ganz ähnlich sieht es beim Upload aus:

curl ftp://speedtest.tele2.net/1GB.zip -o speedtest.zip
curl -T speedtest.zip ftp://speedtest.tele2.net/upload/
21. April: Ø 230 MBit/s
22. April: Ø 78 MBit/s
23. April: Ø 208 MBit/s
24. April: Ø 53 MBit/s

Auch hier streut die erzielte Leistung sehr stark, sodass man sich nicht auf hohen Durchsatz verlassen kann. Zudem habe ich ein Einbrechen der Upload-Rate nach einigen Sekunden beobachtet, sodass die Datenrate zu Ende des Tests teilweise sogar ~ 160 MBit/s niedriger war, als noch zu Beginn.

Die geringen Datenraten und ein Einbrechen selbiger konnte ich während meiner Tests auf meinen Servercow.de Servern nicht nachvollziehen - Hier wurden die erwarteten Datenraten erreicht.

Ping:

Die Ping-Latenzen sind völlig okay. Zu Google.de: 0.6 ms. Bedingt durch den günstigen RZ-Standort Frankfurt am Main in der Nähe des DE-CIX sind allgemein gute Latenzzeiten zu erwarten.

IPv6 Unterstützung

FarnoX ordnet standardmäßig jedem vServer ein eigenes IPv6-Netz zu, sodass einem mehr als genug IPv6-Adressen zur Verfügung stehen. Nach einer Debian-Installation auf dem Server muss IPv6 allerdings manuell eingerichtet werden.

Reverse DNS

Reverse-DNS Einträge können vom Kunden derzeit noch nicht selbstständig eingerichtet werden. Eine entsprechende Benutzerschnittstelle ist aber in Arbeit. Bis zur Fertigstellung können rDNS-Records über den Support angefragt werden.

Traffic-Volumen

Jedem der verfügbaren vServer ist ein Traffic-Volumen zugeordnet. Auf Nachfrage (und weil mir beim Testserver kein verbrauchter Traffic angezeigt wurde) wurde mir erklärt, es gäbe aktuell noch kein Limit, das tatsächlich durchgesetzt würde. Vielmehr hätte jeder Kunde noch die Freiheit, unbeschränkt viel Traffic zu generieren. Eine Beschränkung (vermutlich in Form einer Drosselung) würde langfristig angestrebt.

Vertrag / Angebot

FarnoX.de gibt bei seinen Servern zwei Preise an: Einen Stundenpreis und einen Monatspreis. Regulär wird der Stundenpreis berechnet: Wer einen Server nur 24 Stunden lang nutzt und dann löscht, zahlt auch nur diesen Zeitraum in Stundentaktung. Erreicht ein Server eine Lebenszeit von einem Monat, wird stattdessen der günstigere Monatspreis herangezogen und in Rechnung gestellt. Wer die Server des Anbieters zuerst testen möchte, kann für 7 Tage einen kleinen, kostenlosen Testserver anfordern. Mehr als eine E-Mail Adresse ist dazu (noch) nicht notwendig. Der Server steht (wie auch alle anderen) innerhalb von einer Minute bereit.

Als Zahlungsmittel werden Kreditkarten, PayPal, Lastschrift und Banküberweisung akzeptiert.

Abseits der angebotenen Serverpakete können auch individuell konfigurierte Server über den Support angefordert werden. Ein entsprechender Hinweis auf der Website fehlt leider.

Rechenzentrum / Technik

Meinen Recherchen zufolge nutzt FarnoX.de eigene Hardware im Interwerk-Rechenzentrum in Frankfurt und greift dabei anscheinend auf das Colocation-Angebot von Active-Servers.com zurück. Das bedeutet: Eigene Hardware im Netz von Active-Servers.com und damit betrieben mit 100% Ökostrom der Firma “Lichtblick”.

Die Server werden via KVM virtualisiert und sind damit vollwertige virtuelle Maschinen ohne Einschränkungen bzgl. Kernel. FarnoX bietet seine Server mit CentOS, Fedora, Debian und Ubuntu an. Soll ein spezielles ISO zur Installation verwendet werden, kann dies über den Support angefragt werden.

Auf Anfrage habe ich erfahren, dass FarnoX eine Erreichbarkeit von 99,97 % im Jahr garantiert. Das sollte für die meisten Szenarien im privaten Umfeld absolut ausreichend sein. Überprüfen konnte ich das innerhalb des kurzen Testzeitraums selbstverständlich nicht. Unglücklicherweise war mein Server zwar für eine Stunde nicht erreichbar, aber das lässt sich freilich nicht auf das ganze Jahr hochrechnen.

Dem Kunden zugängliche Backups der virtuellen Server gibt es übrigens nicht. Ich gehe davon aus, dass der Anbieter zwar eine funktionierende Desaster Recovery hat, trotzdem ist es nicht möglich, selbst Sicherungen zu erstellen und als Image herunterzuladen (wie bei Servercow.de).

Sicherheit

Details zur Zugangssicherheit im “Interwerk”-Rechenzentrum können auf der Firmenhomepage nachgelesen werden. Was die informationstechnische Sicherheit angeht, habe ich leider ein paar Mängel festgestellt, die meinen Eindruck etwas trüben:

Zur Änderung des Passworts muss das aktuelle Passwort nicht angegeben werden
Zwei-Faktor-Authentifizierung wird nicht angeboten
Die Remote-Konsole im Webbrowser verbindet sich unverschlüsselt zum Zielserver (inzwischen behoben!)

Während ich die ersten beiden Punkte weniger kritisch sehe, sehe ich bei der unverschlüsselten Remote-VNC-Konsole einen großen Sicherheitsmangel, der sofort behoben werden sollte! Der Hoster ist diesbezüglich bereits kontaktiert.

Update am 26.04.2017 um 15:18: Der Hoster hat die Schwachstelle bei der Remote-Konsole behoben und die Verbindung wird nun verschlüsselt.

Sonstiges

Website

Die Website ist einfach und konsistent gehalten und bietet nicht viel Gelegenheit, sich zu verlaufen. Leider könnte man auch sagen, der Webauftritt sei etwas “zu” einfach gehalten. Nicht alle Fragen, die ich als Neukunde hatte, konnten durch Recherche auf der Site beantwortet werden, z.B. “Was passiert, wenn ich das angegebene Traffic-Volumen überschreite?”, “Kann ich zusätzliche IPv4-Adressen buchen?”, “Welche Verfügbarkeit kann garantiert werden?”.

Support

Der Erfolg eines Hosters steht und fällt mit dem Support. Egal, ob es nur Fragen gibt oder ob ein Eingriff wegen technischer Probleme notwendig ist: Der Support sollte innerhalb eines angemessenen Zeitfensters (ggf. innerhalb von Minuten) antworten und je nach Komplexität des Problems eine Lösung anbieten können. Bisher ergab sich für mich noch keine Gelegenheit, die Reaktion auf techn. Probleme zu testen - Eine E-Mail mit einigen Fragen zum Angebot wurde aber innerhalb von 46 Minuten beantwortet. Das ist kein Bestwert - allerdings sei hierzu angemerkt, dass meine Fragen nicht dringlich waren und die Reaktionszeit für diese Art von Anfrage daher völlig okay. Alle Fragen wurden so beantwortet, wie ich das als Kunde erwarte. Ich würde mir dennoch ein Ticket-System in der Weboberfläche wünschen, über die ich alle Anfragen gesammelt einsehen kann, um besser den Überblick zu behalten. Außerdem könnte man ggf. vertrauliche Daten dem Hoster direkt zukommen lassen, statt sich möglicherweise auf dritte (Mailprovider) verlassen zu müssen.

Fazit

Ich bin mit hohen Erwartungen an den Test herangegangen und wurde bezüglich der verfügbaren Systemleistung nicht enttäuscht: CPU, RAM und SSD sind leistungsstark und erfüllen meine persönlichen Anforderungen an einen vServer der Preisklasse. Ein schneller vServer ist dank Automatisierung und Cloud-Infrastruktur schnell online. Schade, dass im Bereich Internetanbindung deutliche Abstriche gemacht werden müssen: Bisher gibt es zwar keine Volumenbegrenzungen, doch die schwachen Up- und Downloadraten trüben den Gesamteindruck. Hier und da macht es noch den Anschein, als sei der Hoster gerade erst gegründet worden, was sich während des Tests z.B. durch kaputte Links in E-Mails oder temporäre Nichtverfügbarkeit der Homepage/Verwaltung durch abgelaufene TLS-Zertifikate äußerte. Auch in Sachen Kundeninformation ließe sich beispielsweise der FAQ-Bereich noch ausführlicher gestalten. Ein Ticket-System für Bestandskunden ist wünschenswert. Es gibt also noch Optimierungsbedarf. Die Kernaufgabe “schnell und einfach einen Cloudserver online bringen” meistert man bei FarnoX jedoch sehr gut.

Stärken

Möglichkeit, sehr schnell einen Server online zu nehmen
Starke Systemleistung (CPU, RAM, SSD)
Abrechnung in Stundentaktung möglich - ideal für kurzfristige Projekte
Ökostrom

Schwächen

Netzwerk-Performance ins Internet mittelmäßig: Datendurchsatz nicht wie erwartet, stark schwankende Datenrate, keine garantierte Bandbreite.
Zum Teil nachlässiger Umgang mit dem Thema “Sicherheit”: Fehlende 2FA, keine Passwortverifizierung bei Änderung, Klartext-Passwörter in nicht verifizierbarer E-Mail (PGP?)

Anregungen

Wenn das Erstellen von neuen Servern schon so schnell passiert, und auch individuelle Server angeboten werden können, wäre für mich die logische Folge, dem Kunden “ein paar Schieberegler” anzubieten, mit dem er sich ganz einfach schnell seinen Wunschserver konfigurieren und starten kann. Der Weg zu einer individuellen Konfiguration führt aktuell noch über den Support-Weg.

FarnoX kann ich wegen der Stunden-getakteten Abrechnung und des schnellen, unkomplizierten Buchungsprozesses vor allem Entwicklern und Testern empfehlen, die für einen begrenzten Zeitraum einen vServer benötigen.

Offenlegung: FarnoX.de hat mich gebeten, mir ihr Angebot einmal anzusehen und es auszuprobieren. Den Test habe ich freiwillig und ohne jegliche Vorteilnahme aus Eigeninteresse durchgeführt.

Server-Backups mit Borg: So sichere ich meine Server

thomas.leister@mailbox.org (Thomas Leister) — Sat, 08 Apr 2017 19:13:00 +0200

“Kein Backup - kein Mitleid” - ein Motto, das auch ich mir mittlerweile zu eigen mache. Nach einigen Pannen mit fälschlicherweise unwiderruflich gelöschten Dateien musste ich vor einigen Jahren auf schmerzhafte Art und Weise lernen, dass regelmäßige Backups wichtiger Daten nicht ein nettes Feature sind, sondern die Pflicht eines verantwortungsvollen Admins. Das schließt nicht nur Desktop-Rechner ein, sondern vor allem auch Server, die zentrale Dienste bereitstellen, ohne die jeder einzelne User möglicherweise nicht arbeiten kann.

Im Laufe der Jahre habe ich verschiedenste Backup-Lösungen auf meinen Server eingesetzt - Meine aktuelle Lösung gefällt mir aber am besten, daher will ich sie euch in diesem Beitrag kurz vorstellen.

Kernkomponente meines Backup-Setups ist das Backup-Tool “Borg”, welches sich unter Linux-Admins immer größerer Beliebtheit erfreut - und das völlig zu recht. Das Tool ist einfach zu bedienen und ermöglicht im Client-Server Modell sehr effiziente Sicherungen. Sowohl beim Datentransport zum Backup-Storage als auch bezüglich des verbrauchten Speichers.

Borg Installation

Borg gibt es als fertige Pakete für Debian, Ubuntu, und Arch Linux. Neben der Installation über den Paketmanager gibt es auch noch die Installation via pip, oder manuell über ein einzelnes Binary, welches schon alle Abhängigkeiten enthält. Es ist vorteilhaft, auf Backupserver und dem zu sichernden Server (im folgenden einfach “Server” genannt) dieselbe Version von Borg zu nutzen, um Probleme durch eventuelle Inkompatibilitäten zu vermeiden. Die verschiedenen Installationsarten sind im Borg Guide ausführlich erklärt - ich werde daher nicht darauf eingehen.

Konfiguration des Backupservers

Als Backupserver verwende ich meinen NAS-Eigenbau Zuhause. Der Server läuft durchgängig, und eignet sich nicht nur hervorragend als Archiv- und Backupserver für die heimischen Geräte, sondern auch für meine Server. Dank 100 MBit/s / 40 MBit/s DSL und des intelligenten Delta-Datenabgleichs sind auch größere Datenmengen relativ zügig Zuhause gesichert - und nebenbei ist damit auch noch ein sog. “Off-Site-Backup” gemacht, also ein Backup, welches geographisch getrennt von den Produktivservern gelagert wird.

Auf dem Backupserver habe ich einen eigenen Benutzer serverbackup angelegt, dessen Home-Verzeichnis auf einer eigenen, verschlüsselten Partition liegt. So wird verhindert, dass Serverbackups (unbeabsichtigt) ausufern und große Teile des verfügbaren Speichers belegen. Meine Server melden sich jeweils als serverbackup-User an, um sich via SSH zu verbinden und die zu sichernden Daten über eine SFTP-Verbindung zu übertragen. Nach Anlegen des neuen Nutzers auf dem Backupserver wird also auf jedem der anderen Server für den jeweiligen root-Nutzer ein SSH-Key generiert, falls noch nicht vorhanden:

ssh-keygen -a 100 -t ed25519

Die Public Keys aller Server werden gesammelt und auf dem Backupserver in die ~/.ssh/authorized_keys Datei eingetragen, etwa so:

ssh-ed25519 AAAAB3NzaC1yc2EAAAADAQABAAABAQDO67aeTjQwIuuqgxEVasVH root@server1
ssh-ed25519 N3Vb3Nfdgdf1yc2gfAAJen4mJQgfhLgefgh4NhbenHGDsdf62mNe root@server2

Tipp: Am schnellsten lassen sich die Public Keys übertragen, indem man auf jedem Server den gesamten Key im Terminal ausgeben lässt:

cat ~/.ssh/id_ed25519.pub

… und den Inhalt dann auf dem Backupserver z.B. im nano Editor via Copy & Paste einfügt.

Eine Verbindung zum Borg-Backupserver wäre damit eigentlich schon möglich. Doch nehmen wir mal an, einer der Server wird kompromittiert: Ein Angreifer hätte dann ggf. Zugriff auf den Private Key des Servers und damit auch auf den serverbackup-User des Backupservers. Nichts würde ihn daran hindern, weiteren Schaden anzurichten und z.B. alle Backups auf dem Backupserver zu löschen, bevor der gekarperte Server missbraucht oder zerstört wird. Es gilt also zu verhindern, dass einer der Server über die SSH-Verbindung etwas anderes tut, als Backups zu übertragen. Daher wird die gerade bearbeitete authorized_keys Datei wie folgt erweitert:

command="borg serve --restrict-to-path /home/serverbackup/backups/server1 --append-only" ssh-ed25519 AAAAB3NzaC1yc2EAAAADAQABAAABAQDO67aeTjQwIuuqgxEVasVH root@server1
command="borg serve --restrict-to-path /home/serverbackup/backups/server2 --append-only" ssh-ed25519 N3Vb3Nfdgdf1yc2gfAAJen4mJQgfhLgefgh4NhbenHGDsdf62mNe root@server2

Das vorangestellte command=" [...] " sorgt dafür, dass via SSH nur noch die gewünschten Borg-Kommandos ausgeführt werden können - und zwar nur “hinzufügend” (--append-only). Außerdem wird das Verzeichnis festgelegt, innerhalb dessen sich der verbundene Server aufhalten darf (--restrict-to-path). Amok laufende Server stellen dann keine Gefahr mehr für die Backups dar.

Die angegebenen Verzeichnisse für die Backups der Server im serverbackup-Homeverzeichnis müssen selbstverständlich noch angelegt werden. Damit Borg die Backupverzeichnisse als solche erkennt, muss noch ein borg init ausgeführt werden:

mkdir -p /home/serverbackup/backups/server1
borg init /home/serverbackup/backups/server1
mkdir /home/serverbackup/backups/server2
borg init /home/serverbackup/backups/server2

Die Eingabe einer Passphrase wird mit 2x [ENTER] übersprungen. Damit ist der Backupserver vorbereitet.

Konfiguration der zu sichernden Server

Widmen wir uns nun den Servern, von denen regelmäßig Sicherungen angelegt werden sollen. Borg sollte hier bereits installiert sein. Die Backups werden vom root-User durchgeführt, da in den meisten Fällen nur er Zugriff auf alle wichtigen Daten hat.

Der Backup-Prozess wird durch einen sog. Cron Job ausgelöst und von einem einfachen Bash-Script ausgeführt, welches Vorbereitungen durchführt und letztendlich Borg nutzt, um das Backup auf Dateiebene zu starten. Um jede Nacht ein Backup um 00:00 Uhr zu starten, kann beispielsweise folgender Cronjob eingetragen werden (Cronjob-Editor öffnen via crontab -e als root.):

@daily /root/backup/backup.sh > /dev/null 2>&1

Mein Backup-Script in /root/backup/backup.sh sieht wie folgt aus:

#!/bin/bash
##
## Save backup to directory named after hostname
##
LOG="backup.log"
HOST=`hostname`
REPOSITORY="ssh://serverbackup@backupserver.tld:22/~/backups/"$HOST
##
## Write output to logfile
##
exec > >(tee -i ${LOG})
exec 2>&1
echo "###### Starting backup on $(date) ######"
##
## Create list of installed software
##
dpkg --get-selections > /root/backup/software.list
##
## Create database dumps
##
echo "Creating database dumps ..."
/bin/bash /root/backup/dbdump.sh
##
## Sync backup data
##
echo "Syncing backup files ..."
borg create -v --stats \
$REPOSITORY::'{now:%Y-%m-%d_%H:%M}' \
/root/backup \
/etc \
/var/www \
/var/vmail \
/storage
echo "###### Finished backup on $(date) ######"
##
## Send mail to admin
##
mailx -a "From: "$HOST" Backup <"$HOST"@meinedomain.tld>" -s "Backup | "$HOST admin@meinedomain.tld < $LOG

Folgende Daten werden gesichert:

Liste aller installierten Softwarepakete
Ein Dump aller Datenbanken, die in dbdump.sh definiert sind (dazu gleich mehr)
Dateien aus den angegebenen Verzeichnissen (/etc, /var/www, … )

Sämtliche Ausgaben, die während des Backupprozesses entstehen, werden in eine Log-Datei geschrieben und als E-Mail an den Administrator geschickt. Das funktioniert freilich nur, wenn ein funktionierender Mailserver auf dem System installiert ist.

Datenbanken sichern

Die Sicherung der MySQL-Datenbanken übernimmt ein eigenes Script /root/backup/dbdump.sh:

#!/bin/bash
DBUSER="backup"
DBPASSWD="backupuserpassword"
DBBAKPATH="/root/backup/dbdumps/"
DBS="nextcloud vmail spamassassin"
for DBNAME in $DBS; do echo "Creating backup for database $DBNAME" && mysqldump -u $DBUSER -p$DBPASSWD $DBNAME > $DBBAKPATH"$DBNAME.sql"; done

Damit das Script funktioniert, muss im /root/backup Verzeichnis ein Unterverzeichnis “dbdumps” existieren. Nur die in “DBS” definierten Datenbanken werden vom Backup erfasst. Auf dem MySQL-Server muss ein spezieller Backup-User “backup” mit dem dazugehörigen Passwort angelegt werden. Dieser hat lesenden Zugriff auf alle Datenbanken und Tabellen:

mysql -u root -p
create user 'backup'@'localhost' identified by 'backupuserpassword';
grant SELECT, RELOAD, LOCK TABLES, REPLICATION CLIENT, SHOW VIEW, EVENT, TRIGGER on *.* to 'backup'@'localhost';
quit;

Das war’s auch schon!

Jetzt noch das Script getestet:

chmod u+x /root/backup/backup.sh
./root/backup/backup.sh

… und das Thema “Backup” ist für’s erste erledigt. Im Grunde müssen jetzt noch noch die eintreffenden E-Mails regelmäßig kontrolliert werden.

Alte Backups automatisch entfernen

Halt, da ist noch etwas! Mit der Zeit werden die Backups langsam aber sicher die zugewiesene Partition auf dem Backupserver füllen. Damit das nicht passiert, macht es Sinn, diese nicht ewig aufzuheben, sondern regelmäßig zu löschen.

Für diese Aufgabe habe ich mir auf dem Backupserver ein weiteres Script /home/serverbackup/prune-backup.sh angelegt:

#!/bin/bash
ROOTDIR="/home/serverbackup/backups/"
LOG="prune-backup.log"
# copy all output to logfile
exec > >(tee -i ${LOG})
exec 2>&1
echo "###### Pruning backup for server1 on $(date) ######"
borg prune -v ${ROOTDIR}server1 \
--keep-daily=7 \
--keep-weekly=4 \
--keep-monthly=6
echo "###### Pruning backup for server2 on $(date) ######"
borg prune -v ${ROOTDIR}server2 \
--keep-daily=7 \
--keep-weekly=4 \
--keep-monthly=6
echo "###### Pruning finished ######"
# Send logfile to serveradmin
mailx -r backup@meinserver.tld -s "Backup | Prune" admin@meinserver.tld < $LOG

Auch dieses Script wird von einem Cronjob ausgelöst - und zwar erst, wenn alle Serverbackups durchgeführt sind. Andernfalls kann es zu Konflikten kommen. Ich lasse das Script zum “Stutzen” des Backups daher erst um 2:00 Uhr täglich laufen. Auf dem Backupserver:

su - serverbackup
chmod u+x ~/prune-backup.sh
crontab -e

Neuer Cronjob:

0 2 * * * ~/prune-backup.sh

Nach einem “prune” bleibt von den Backups nur folgendes übrig:

7 tägliche Backups aus den letzten Tagen
4 wöchentliche Backups aus den letzten 4 Wochen
6 monatliche Backups aus den letzten 6 Monaten

Das heißt: Ich behalte nur so viele Daten, dass ich die täglichen Stände der letzten Woche wiederherstellen kann, oder die wöchentlichen Stände der letzten 4 Wochen, oder die monatlichen Stände des letzten halben Jahres. Länger als 6 Monate wird kein Backup aufbewahrt.

Backups wiederherstellen

… und das sollte geübt sein: Im Notfall soll es schließlich schnell und routiniert funktionieren. Daher hier die notwendigsten Kommandos:

Liste der vorhandenen Backups einsehen

Entweder auf dem Backupserver: (in den meisten Fällen weniger komfortabel)

cd /home/serverbackups/backups/server1
borg list

… oder direkt auf dem betroffenen Server (als root):

borg list ssh://serverbackup@backupserver.tld:22/~/backups/server1

Die Ausgabe kann z.B. so aussehen:

2017-04-07_00:04 Fri, 2017-04-07 00:01:18
2017-04-08_00:04 Sat, 2017-04-08 00:00:56

Ein Verzeichnis wiederherstellen

Um eine spezielle Version eines Verzeichnisses oder einer Datei aus dem Backup-Archiv zu extrahieren, wird das borg extract Kommando genutzt. Beispiel: Das Verzeichnis /var/www vom 08.04.2017 soll vom Server aus wiederhergestellt und nach /backup-extracted/www geschrieben werden:

mkdir -p /backup-extracted/www
cd /backup-extracted/www
borg extract ssh://serverbackup@backupserver.tld:22/~/backups/server1::2017-04-08_00:04 var/www

Vorsicht: Der borg extract Befehl extrahiert die Daten in das aktuelle Verzeichnis: Daher erst in das Zielverzeichnis navigieren - dann borg extract absetzen!

Der entsprechende Wiederherstellungsbefehl auf dem Backupserver könnte beispielsweise lauten:

borg extract ~/backups/server1::2017-04-08_00:04 var/www

Je nach Netzwerkverbindung und Systemleistung kann das Wiederherstellen eines Backups einige Zeit in Anspruch nehmen. In den meisten Fällen muss es nämlich zuerst aus mehreren inkrementellen Backups zusammengesetzt werden.

So. Das war’s jetzt aber wirklich.

Nginx Reverse Proxy mit dynamischem Zielhost

thomas.leister@mailbox.org (Thomas Leister) — Sun, 02 Apr 2017 07:42:00 +0200

Für meine Statusseite https://status.trashserver.net setze ich aus verschiedenen Gründen einen eigenen Reverse Proxy ein, um auf der Übersichtsseite von Uptimerobot.com HTTPS TLS-Verschlüsselung anbieten zu können. Nach der Einrichtung meines Nginx Webproxies war die Statusseite jedoch regelmäßig nicht mehr erreichbar (“502 - Bad Gateway”). Erst nach einem Neustart von Nginx konnte die Seite wieder aufgerufen werden. Die Ursache für die regelmäßigen Unterbrechungen war eine dynamische IP-Adresse hinter dem Zielhost “stats.uptimerobot.com”. Mit folgender, klassischer Konfiguration wird der Zielhost nur ein Mal beim Start von Nginx aufgelöst:

server {
server_name status.trashserver.net;
[...]
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-NginX-Proxy true;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass https://stats.uptimerobot.com;
proxy_redirect off;
}
[...]
}

Wenn die zum Start ermittelte IP-Adresse sich ändert und nicht mehr auf den erwarteten Host zeigt, kommt es zum beschriebenen Fehler. Ich habe also nach einer Möglichkeit gesucht, Nginx dazu zu zwingen, den Hostnamen regelmäßig neu aufzulösen. Bei tenzer.dk bin ich fündig geworden: Setzt man den Upstream in Form einer Variablen, und gibt einen Resolver an, verhält sich Nginx wie gewünscht und kommt auch mit dynamischen IP-Adressen zurecht:

server {
server_name status.trashserver.net;
[...]
resolver 192.168.2.1;
set $upstream1 https://stats.uptimerobot.com/rk3R0IDJq/;
set $upstream2 https://stats.uptimerobot.com;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-NginX-Proxy true;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass $upstream1;
proxy_redirect off;
}
location ~ ^/(.+) {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-NginX-Proxy true;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass $upstream2;
proxy_redirect off;
}
}

Dezentrales HA Servercluster-VPN mit PeerVPN

thomas.leister@mailbox.org (Thomas Leister) — Sun, 12 Mar 2017 12:39:00 +0100

Um hochverfügbare Dienste zu hosten, empfiehlt es sich, Server bei mehreren Hostern in verschiedenen, geografisch verteilten Rechenzentren zu betreiben. Die Server-to-Server-Kommunikation innerhalb des Serverclusters sollte dabei verschlüsselt stattfinden. Das lässt sich am einfachsten über ein Cluster-eigenes VPN erreichen - also ein privates Netzwerk, das nur dem sicheren Informationsaustausch der Server untereinander dient. Ich habe mich nach einer passenden VPN-Lösung für ein Projekt umgesehen und habe die für mich perfekte Softwarelösung gefunden: PeerVPN von Tobias Volk.

PeerVPN hebt sich von der Vielzahl der OpenSource VPN Projekte durch folgende Eigenschaften ab:

PeerVPN ist klein und einfach. Die Einrichtung ist für geübte in weniger als einer Minute erledigt und bedarf keiner Einarbeitung.
PeerVPN bildet ein voll vermaschtes Peer-to-Peer Netzwerk. Das heißt: Auf einen zentralen Server (Single Point of Failure!) kann verzichtet werden.
Authentifizierung via Shared Key

Installation unter Debian Jessie

Im folgenden erkläre ich die Installation von PeerVPN unter Debian 8 (Jessie). Die Vorgehensweise lässt sich in den meisten Fällen auch auf alle anderen Debian-basierten Linux-Distributionen übertragen (z.B. Ubuntu Server).

Wir werden PeerVPN aus dem offiziellen Quellcode auf GitHub selbst kompilieren. Das ist schnell erledigt und überraschend schmerzfrei. Dafür benötigen wir zunächst einige Pakete, die nachinstalliert werden müssen, falls sie nicht schon auf dem System installiert sind:

apt update && apt install git build-essential

Quellcode herunterladen:

git clone https://github.com/peervpn/peervpn/
cd peervpn

PeerVPN benötigt OpenSSL 1.0 oder LibreSSL, um zu funktionieren. Debian Jessie kommt mit OpenSSL 1.0. Leider ist PeerVPN aktuell nicht mit dem neueren OpenSSL 1.1 kompatibel, welches in künftigen Debian Stable Releases enthalten sein wird. Stattdessen kann LibreSSL genutzt werden.

Kompilieren mit OpenSSL 1.0

Wer Debian Jessie oder eine andere Linux-Distribution mit OpenSSL 1.0 verwendet, kann das libssl-dev Paket installieren, und PeerVPN direkt kompilieren:

apt install libssl-dev

Quellcode kompilieren:

make -j2

(-j2 zum Kompilieren mit 2 CPU-Kernen, -j4 für 4 Kerne etc.)

Kompilieren mit LibreSSL

Wenn kein OpenSSL 1.0 verfügbar ist oder LibreSSL verwendet werden soll, kann PeerVPN problemlos auch mit LibreSSL kompiliert werden. Dafür wird im heruntergeladenen Git-Verzeichnis die Datei “build.sh” mit diesem Inhalt angelegt:

#!/bin/sh
libressl_version=libressl-2.5.1
libressl_archive=${libressl_version}.tar.gz
if [ -f ${libressl_archive} ]
then
:
else
wget -O ${libressl_archive} https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/${libressl_archive}
fi
if [ -f ${libressl_archive} ]
then
:
else
echo wget failed.
return -1
fi
libressl_lib=${libressl_version}/crypto/.libs/libcrypto.a
if [ -f $libressl_lib ]
then
:
else
tar -xzf ${libressl_archive}
cd ${libressl_version} && ./configure && make && cd ..
fi
cc -O2 -I${libressl_version}/include peervpn.c -o peervpn ${libressl_version}/crypto/.libs/libcrypto.a && echo success!

(Script auf GitHub Gist)

Das Script lädt LibreSSL herunter und generiert eine statisch gelinkte Version von PeerVPN. Achtet darauf, dass im Script eine aktuelle LibreSSL-Version angegeben ist! (https://www.libressl.org/)

PeerVPN auf dem System installieren:

cp peervpn /usr/local/bin

PeerVPN konfigurieren

Konfigurationsverzeichnis erstellen:

mkdir /etc/peervpn

Im Konfigurationsverzeichnis wird die Datei “vpn.conf” angelegt:

networkname PEERVPN
psk meinsupergeheimerschlüssel
interface peervpn0
port 7000
ifconfig4 10.0.2.1/24
initpeers host2.domain.tld 7000 host3.domain.tld 7000

networkname: Frei wählbarer Netzwerkname
psk: Schlüssel, gemeinsamer, geheimer Schlüssel, über den sich die Teilnehmer authentifizieren
interface: Interface-Name für das zu erstellende Netzwerk-Interface
port: Port, der für die Kommunikation zwischen den Nodes genutzt werden soll
ifconfig4: IP-Adresse des jeweiligen Servers im VPN. (Individuell für jeden Host!)
initpeers: Auf einem der Hosts werden über “initpeers” alle anderen Hosts definiert. Das ist notwendig, damit die Teilnehmer beim Start des Netzwerks untereinander bekannt gemacht werden können. Syntax: initpeers <host> <hostport> <host> <hostport> ...

Systemd-Service

Auf jedem der Teilnehmerhosts wird außerdem ein Systemd-Service eingerichtet, welcher PeerVPN nach dem Systemstart automatisch initiiert:

Datei /etc/systemd/system/peervpn@.service anlegen:

[Unit]
Description=PeerVPN Node (%i)
After=syslog.target network.target
ConditionPathExists=/etc/peervpn/%i.conf
[Service]
Type=simple
ExecStart=/usr/local/bin/peervpn /etc/peervpn/%i.conf
[Install]
WantedBy=multi-user.target

VPN Service Aktivieren und starten:

systemctl enable peervpn@vpn.service
systemctl start peervpn@vpn.service

Test

Nachdem PeerVPN auf allen Hosts installiert und gestartet wurde, kann es einige Sekunden dauern, bis sich die Teilnehmer untereinander vernetzt haben. Den aktuellen Vernetzungsstatus eines Teilnehmers kann u.A. via

systemctl status peervpn@vpn.service

abrufen. Im Log wird mitprotokolliert, zu wie vielen anderen Hosts eine Verbindung besteht.

Ein einfacher Verbindungstest kann via ping erfolgen:

ping 10.0.2.1
ping 10.0.2.2
...

Bestehende Dienste wie z.B. Webserver oder Datenbankserver können nur an die jeweilige 10.0.2.x -IP-Adresse des Hosts gebunden werden, sodass sie nur über das VPN erreichbar sind.

thomas-leister.de

Restic mit Hetzner Storagebox nutzen

Einen neuen Host registrieren

Backupscript erstellen

Der Yubikey im Praxiseinsatz

Einsatzzwecke

Absicherung Logins

Mit U2F

Mit TOTP

Absicherung Passwortdatenbank

KeePassXC Screenshot

Ein Backup des Yubikeys erstellen

Fazit

Mein Mini Backup NAS mit Rock64 Single Board Computer

Hardware

Teileliste und Preise

Software

Leistung

SSD

Ethernet

SD-Karte

SFTP

Samba

NFS v4

Fazit

TeamViewer für das CLI: Terminal-Sessions freigeben

Freigabe mit Screen

Freigabe mit Tmux

Freigabe via SSH und Webinterface mit Tmate

Fedora 27: ED25519 OpenSSH Keys nach Benutzung entsperrt lassen

Einen zentralen Mailserver (Mail-Gateway) mit weiteren Hosts nutzen

Postfix-Grundkonfiguration auf dem externen Host

Externen Mailempfang auf den Hosts abschalten

Eine main.cf nur für den Nachrichtenversand

Fall 1: Externer Host mit statischer IP-Adresse

Fall 2: Externer Host mit dynamischer IP-Adresse (z.B. Homeserver)

Lokale Mailzustellung auf externen Hosts verhindern und Mails weiterleiten

Setup testen

Systemd: Service-Start von Netzwerk-Interface abhängig machen

Ein neues Systemd-Target einführen

Weitere Dienste vom Target abhängig machen

Ein Wartungsnetz für meine Server-Infrastruktur mit PeerVPN und Docker

Eine komfortable Lösung: PeerVPN im Docker-Container

VPN Deployment auf den Hosts

1) Docker-Compose File auf den Host kopieren

2) PeerVPN starten

Automatische Updates mit Watchtower

Fazit

Powerwalker UPS unter Debian 9 Stretch

UPS-Monitoring mit NUT

Treiber einrichten und UPS verfügbar machen

UPSd konfigurieren

UPSMon konfigurieren

NUT starten

UPS-Werte ausgeben

Mailserver mit Dovecot, Postfix, MySQL und Rspamd unter Debian 9 Stretch

Mailserver-Funktionen

Verwendete Software

Gegebenheiten

Grundvoraussetzungen für den Mailserver

Komponenten eines vollständigen Mailsystems

Dovecot

Postfix

MariaDB (MySQL-Datenbank)

Rspamd

Nginx (optional)

Redis

Vorbereitungen

Tipp: Reinen Tisch machen

Login als Root

System aktualisieren

Hostname und Server-FQDN setzen

Tipp: Unbound DNS Resolver installieren

Einrichtung des DNS

Reverse DNS

SPF-Records

DMARC Records

Einrichtung der TLS-Zertifikate (Let’s Encrypt)

Abholen neuer Zertifikate

Automatische Erneuerung