Let’s Encrypt Zertifikate für Postfix und Dovecot einrichten

In letzter Zeit wird die Verwendung der kostenlosen Zertifikate von Let’s Encrypt immer beliebter. Deshalb ist es naheliegend, diese auch für Verschlüsselung der Mails bei Postfix zu verwenden. Im folgenden sind die wenigen Schritte für die Einrichtung erklärt, die bei einem Ubuntu 18.04 notwendig sind.

Installation

Let’s Encrypt können mit dem certbot erzeugt werden. Die Installation des Programms bei Ubuntu 18.04 erfolgt mit den folgendenBefehlen.

sudo apt update
sudo apt install python-certbot-apache

Erzeugung eines Zertifikates

Das Zertifikat wir mit dem Programm certbot erzeugt. Da die Verifizierung des Host über den Webauftritt erfolgt. Ist es zwingend erforderlich, dass ein Apache auf dem Server installiert ist. Das Programm certbot macht dann die notwendigen Anpassungen an der Konfiguration des Apache Webservers. Mit der Option -d werden die Hostnamen angegeben, für welche das Zertifikat ausgestellt werden soll. Dabei ist es möglich das Zertifikat gleich für mehrere Hostnamen auszustellen. Nach dem ausführen des Programms certbot werden zudem einige Fragen gestellt, deren Beantwortung für das anpassen der Konfiguration des Apache Webservers notwendigen sind. Mit dem folgenden Befehl testet man z.B. das Ausstellen eines Zertifikates für die Hostnamen www.purrucker.de, purrucker.de imap.purrucker.de und smtp.purrucker.de. 

sudo certbot --apache --staging -d www.purrucker.de -d purrucker.de -d imap.purrucker.de -d smtp.purrucker.de

Wenn alles funktioniert, kann man das Kommando ohne die Option „–staging“ ausführen. Dann fordert certbot beim Let’s-Encrypt-Projekt die generierten Zertifikate an, lädt diese herunter, installiert alle erforderlichen Dateien in das Verzeichnis /etc/letsencrypt, verändert die Apache-Konfiguration und startet Apache schließlich neu.

Einbindung des Zertifikates

Die Einbindung des Zertifikates in den Apache Webserver hat das Programm certbot erledigt. Bei Postfix und Dovecot muss die Einbindung jedoch von Hand erfolgen. Bei Postfix fügt man dazu die beiden folgenden Zeilen in die Datei /etc/postfix/main.cf ein.

smtpd_tls_cert_file= /etc/letsencrypt/live/www.purrucker.de/fullchain.pem
smtpd_tls_key_file= /etc/letsencrypt/live/www.purrucker.de/privkey.pem

Bei Dovecot benötigt man die drei folgenden Zeilen in der Datei /etc/dovecot/conf.d/10-ssl.conf.

ssl = yes
ssl_cert = </etc/letsencrypt/live/www.purrucker.de/fullchain.pem
ssl_key  = </etc/letsencrypt/live/www.purrucker.de/privkey.pem

Danach müssen beide Programme einmal neu gestartet werden.

service postfix restart
service dovecot restart

Automatische Erneuerung des Zertifikates

Das Let’s Encrypt Zertifikat ist grundsätzlich immer nur drei Monate gültig. Deshalb ist es notwendig, dieses regelmäßig zu erneuern. Um dies nicht immer von Hand machen zu müssen, sollte man sich dazu einen wöchentlichen Cronjob anlegen. Dazu einfach die Datei /etc/cron.weekly/letsencrypt mit folgendem Inhalt anlegen und ausführbar machen.

#!/bin/sh
# Datei /etc/cron.weekly/letsencrypt
certbot renew
result=$(find /etc/letsencrypt/live/ -type l -mtime -1 )
if [ -n "$result" ]; then
  systemctl restart postfix
  systemctl restart dovecot
fi

SPAM-E-Mails aus der Postfix-Queue löschen

Heute wurden mit einem geklauten Benutzerzugang über einen unserer Server innerhalb weniger Minuten ca. 10.000 SPAM-E-Mails verschickt. Ich habe den betroffenen Zugang natürlich sofort gesperrt, nachdem durch die Hohe Anzahl von E-Mails der Alarm ausgelöst wurde. Aber was macht man jetzt mit den ganzen E-Mails in der Queue von Postfix?

Durch eine Analyse der E-Mail-Adressen der Empfänger in der Ausgabe des Befehls mailq zeigte sich, dass die E-Mail-Adressen eine bestimmte Systematik hatten. Die meisten enthielten das word admin. Durch die Kombination von ein paar Unix-Befehlen konnte ich deshalb die meisten SPAM-E-Mails löschen, bevor sie versendet wurden. Hier der Befehl, welchen ich dazu verwendet habe:

mailq | awk 'BEGIN { RS = "" } / admin@.*$/ { print $1 }' | tr -d '*!' | postsuper -d -

ISPConfig: Upgrade von Ubuntu 10.04 auf 12.04

Ich habe heute mal einige Server die ich mit ISPConfig (aktuell Version 3.0.5.2) verwalte auf Ubuntu 12.04 aktualisiert. Nachdem Ubuntu 12.04 nun ziemlich genau ein Jahr draußen ist, war die Zeit nach meiner Meinung reif für ein Upgrade.

Das Upgrade lief auch ohne größere Probleme durch. Ich habe aber bei MySQL aus Kompatibilitätsgründen wieder MyISAM als Standard-Tabellentyp eingestellt. Dies kann mit der Zeile

default-storage-engine = MyISAM

in der Datei /etc/mysql/my.cnf bewerkstelligt werden.

Des weiteren hat Postfix ein bisschen rumgezickt. Beim starten hat es einige Zeilen in der main.cf und master.cf angemaul, die nicht mehr unterstützt werden. Diese kann man aber einfach auskommentieren. Außerdem lief die SASL-Authentifizierung von Postfix nicht mehr. Deshalb konnte man keine E-Mails per Authentifizierung verschicken. Die Lösung des Problems wird im Launchpad unter der folgenden URL aber schon beschrieben: https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/875440/comments/34. Offensichtlich hat sich hier in der Schreibweise einiger Parameter etwas geändert. Wenn man die Datei /etc/postfix/sasl/smtpd.conf wie folgt abändert, läuft es wieder:

pwcheck_method: saslauthd
mech_list: plain login pam
allow_plaintext: true
auxprop_plugin: sql
sql_engine: mysql
sql_hostnames: 127.0.0.1
sql_user: [entfernt]
sql_passwd: [entfernt]
sql_database: dbispconfig
sql_select: select password from mail_user where login = '%u@%r'

Mit Postfix einen BCC automatisch setzen

Ab Postfix 2.1 kann man mit der Direktive recipient_bcc_maps einen BCC (blind carbon-copy) Empfänger automatisch setzen lassen.

Wenn man bei E-Mails von user1@domain1.com automatisch user2@domain2.com als BCC Empfänger setzen möchte, legt man eine Datei /etc/postfix/recipient_bcc an, die wir folgt aussehen sollte:

user1@domain1.com user2@domain2.com

Danach erzeugt man eine Hash-Tabelle aus der Datei:

postmap /etc/postfix/recipient_bcc

Zum Schluss bindet man die Datei in Postfix ein, indem man in die Datei main.cf zusätzlich die folgende Zeile schreibt und Postfix einmal neu startet:

recipient_bcc_maps = hash:/etc/postfix/recipient_bcc

Verbesserung des SPAM-Schutzes bei ISPConfig 3 / Postfix

Wenn man einen Linux-Server mit ISP-Config 3 nach Anleitung installiert, ist der SPAM-Schutz des Postfix meist noch verbesserungswürdig. Meine Meinung nach sollte man auf jeden Fall strengere Kriterien für E-Mail-Absender einbauen. Es sollten z.B. keine E-Mails von unvollständigen Domains angenommen werden und eine SBL (SPAM Block List) wie Spamhaus eingebunden werden. Dazu muss man in der Datei /etc/postfix/main.cf die Zeile

smtpd_sender_restrictions = check_sender_access mysql:/etc/postfix/mysql-virtual_sender.cf

wie folgt erweitertern.

smtpd_sender_restrictions = reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client cbl.abuseat.org, reject_non_fqdn_sender, reject_unknown_sender_domain, check_sender_access mysql:/etc/postfix/mysql-virtual_sender.cf

Postfix nach gültigen Emailadressen auf einem Exchangeserver fragen lassen

Häufig wird zwischen Internet und dem internen Mailserver ein Linux mit Postfix eingesetzt, um unerwünschte Viren und SPAM nicht in das Firmennetzwerk gelangen zu lassen.

Postfix Mailproxy

Oft wird dabei eingestellt, dass alle Emails für die interne Domäne angenommen und an den internen Emailserver weiter geleitet werden, da Postfix die gültigen Emailadressen des internen Emailservers nicht kennt. Daraus ergeben sich jedoch zwei Probleme:

  1. Es werden auch Viren und SPAM für ungültige Emailadressen angenommen und untersucht, was unnötige Resourcen verbraucht.
  2. Es werden unnötige Unzustellbarkeitsbenachrichtigungen erzeugt, welche die Warteschlange im Mailserver verstopfen. Hinzu kommt, dass diese bei Viren und SPAM oft an falsche Emailadressen gehen. Dadurch werden zum Teil mehrere Zustellversuche unternommen, wodurch die Warteschlange wiederum noch mehr verstopft.

Um diese Probleme zu umgehen muss Postfix in der Lage sein, Emails an ungültige Emailadressen gar nicht erst anzunehmen. Dazu muss es jedoch die Möglichkeit haben, die Gültigkeit einer Emailadresse zu erfragen. Da Exchange ab der Version 2000 die dazu nötigen Informationen im Active Directory speichert, kann dies mit einer LDAP-Anfrage an einen Windows Domänen Controller geschehen. Ab Postfix 2.1 kann dies mit wenigen Zeilen Konfiguration und der Option relay_recipient_maps eingestellt werden. In der Firewall sollten vorher allerdings LDAP-Anfragen von Postfix an mindestens einen internen Windows Domänen Controller erlaubt werden. Dazu müssen Verbindungen des Postfix auf den TCP-Port 389 des Windows Domänen Controllers erlaubt werden.

Mit der Option relay_recipient_maps kann Postfix dazu gebracht werden nur Emails für gültige Emailadressen der eigenen Domäne weiterzuleiten. Bei unbekannten Emailadressen verweigert Postfix die Annahme einer Email mit der Meldung: Recipient address rejected: User unknown in relay recipient table. Diese existierenden Emailadressen können dabei auch über LDAP abgefragt werden, wenn Postfix mit LDAP-Unterstützung installiert ist (bei Debian muss dazu das Paket postfix-ldap installiert sein). Dazu muss man lediglich die folgende Zeile in die Datei /etc/postfix/main.cf einfügen.


relay_recipient_maps = ldap:/etc/postfix/ldap_relay_recipient_maps.cf

Danach muss die Datei /etc/postfix/ldap_relay_recipient_maps.cf mit den Einstellungen für die LDAP-Abfrage angelegt werden. Für die Abfrage der Emailadressen von den Windows Domän Controllern ad-01 und ad-02 der Domäne example.com als Benutzer postfix sollte sie wie folgt aussehen.


server_host = ad-01.example.com
              ad-02.example.com
search_base = dc=example, dc=com
version = 3

bind_dn = CN=postfix,CN=Users,DC=example,DC=com
bind_pw = password

query_filter = (proxyAddresses=smtp:%s)
result_attribute = mail

Die Voraussetzung ist natürlich, dass es einen Benutzer postfix unterhalb Users in der Domäne example.com gibt. Dieser muss jedoch keine Administrationsrechte haben. Es reicht ein normaler Benutzer.

Ob die Konfiguration in der Datei ldap_relay_recipient_maps.cf funktioniert, kann man als root mit dem folgendem Befehl testen.

/usr/sbin/postmap -q "postmaster@example.com" ldap:/etc/postfix/ldap_relay_recipient_maps.cf

Sofern es die Emailadresse postmaster@example.com gibt, sollte diese als Ausgabe erscheinen. Wenn es keine Ausgabe gibt, existiert diese nicht.

Weiter Infos zu dem Thema sind unter den folgenden Links zu finden: